Congestion control method and device, source end server, switch, storage medium and program product

By generating telemetry data packets by carrying DSCP values ​​in the data packets, the target switch sends them to the source server for congestion control, which solves the data transmission delay problem caused by switch congestion and realizes low-latency data transmission when the switch is not congested.

CN120980015APending Publication Date: 2025-11-18WUXI STARS MICRO SYSTEM TECHNOLOGIES CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202511242687.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-09-01
Publication Date
2025-11-18

AI Technical Summary

Technical Problem

Existing technologies suffer from high data transmission latency when reducing switch congestion.

Method used

By carrying a Differential Service Code Point (DSCP) value in the data packet, the target switch generates a telemetry data packet when it receives a filter value representing a telemetry packet, and sends it to the source server so that the source server can perform congestion control and prevent the data packet from passing through the congested switch.

Benefits of technology

While avoiding switch congestion, it reduces data transmission latency and optimizes network traffic.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120980015A_ABST
    Figure CN120980015A_ABST
Patent Text Reader

Abstract

The invention relates to a congestion control method and device, a source end server, a switch, a storage medium and a program product. The method comprises the following steps: sending a data packet to a target switch; receiving a telemetry data packet sent by the target switch; performing congestion control according to the telemetry data packet; the data packet comprises a differential service code point DSCP value; the telemetry data packet is generated based on the information of the target switch under the condition that the target switch determines that the DSCP value represents the filtering value of the telemetry packet. By adopting the method, the data transmission delay can be degraded under the condition of avoiding the congestion of the switch.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a congestion control method, apparatus, source server, switch, storage medium and program product. Background Technology

[0002] During network communication, the source server sends packets to the destination server via a switch to achieve end-to-end network communication. If multiple source servers send packets to the destination server via a single switch during this process, it will cause switch congestion.

[0003] Currently, the main method to reduce switch congestion is through explicit congestion notification (ECN) marking. This involves including an ECN mark in the message sent by the congested switch to the destination server. The destination server then sends a response message with the ECN mark to the source server via the congested switch. Upon receiving the message with the ECN mark, the source server avoids sending messages to the congested switch, thereby optimizing network traffic and reducing congestion.

[0004] However, the methods mentioned above for reducing switch congestion still suffer from high data transmission latency. Summary of the Invention

[0005] Therefore, it is necessary to provide a congestion control method, device, source server, switch, storage medium, and program product that can reduce data transmission latency while avoiding switch congestion, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a congestion control method applied to a source server, comprising:

[0007] Send a data packet to the target switch; the data packet includes the Differential Service Code Point (DSCP) value;

[0008] Receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on information from the target switch, after determining that the DSCP value represents the filtering value of the telemetry packets;

[0009] Congestion control is performed based on telemetry data packets.

[0010] In one embodiment, the congestion control based on telemetry data packets described above includes:

[0011] Determine the congestion assessment strategy based on the business scenario corresponding to the data packet;

[0012] Congestion control is performed based on telemetry data packets and congestion assessment strategies.

[0013] In one embodiment, the congestion control based on telemetry data packets and a congestion assessment strategy includes:

[0014] Parse the telemetry data packets to obtain the parsing results; the parsing results include the target switch's attribute information and the target switch's operational information;

[0015] Congestion control is performed based on the parsing results and congestion judgment strategies.

[0016] In one embodiment, the congestion control based on the parsing results and the congestion judgment strategy includes:

[0017] Based on the target switch's operational information and congestion assessment strategy, if the target switch is determined to be in a congested state, the target path is determined by querying the preset path table according to the target switch's attribute information; the target path includes the target switch.

[0018] The target path is marked as congested in the preset path table.

[0019] In one embodiment, the operational information of the target switch includes link utilization and queue depth of each output port. Based on the service scenario corresponding to the data packet, a congestion assessment strategy is determined, including:

[0020] In the case of a latency-sensitive business scenario, the congestion judgment strategy includes: if the link utilization is greater than the first threshold, or the queue depth is greater than the second threshold, then the target switch is determined to be in a congested state.

[0021] In the case of a throughput-driven business scenario, the congestion determination strategy includes: if the link utilization is greater than the third threshold and the queue depth is greater than the fourth threshold, then the target switch is determined to be in a congested state.

[0022] In bandwidth-sensitive business scenarios, the congestion determination strategy includes: if the link utilization rate is greater than the fifth threshold, the target switch is determined to be in a congested state.

[0023] In scenarios where the business context is traffic buffering, the congestion determination strategy includes: if the queue depth is greater than the sixth threshold, then the target switch is determined to be in a congested state.

[0024] Secondly, this application provides a congestion control method applied to a switch, comprising:

[0025] Receive data packets sent by the source server; the data packets include the Differential Service Code Point (DSCP) value;

[0026] Given that the DSCP value of the data packet represents the filtering value of the telemetry packet, a telemetry data packet is generated based on the information from the switch.

[0027] Send telemetry data packets to the source server.

[0028] In one embodiment, the above-mentioned generation of telemetry data packets based on switch information includes:

[0029] The target data packet is sampled based on the preset message sampling rate to obtain the sampled data packet; the target data packet is a data packet whose DSCP value represents the filtered value of the telemetry packet.

[0030] Telemetry data packets are generated based on the sampled data packets and information from the switch.

[0031] Thirdly, this application also provides a congestion control device applied to a source server, comprising:

[0032] The sending module is used to send data packets to the target switch; the data packets include the Differential Service Code Point (DSCP) value.

[0033] The receiving module is used to receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on information from the target switch after determining that the DSCP value represents the filtering value of the telemetry packets.

[0034] The control module is used for congestion control based on telemetry data packets.

[0035] Fourthly, this application also provides a congestion control device for use in a switch, comprising:

[0036] The receiving module is used to receive data packets sent by the source server; the data packets include Differential Service Code Point (DSCP) values.

[0037] The generation module is used to generate telemetry data packets based on information from the switch, given that the DSCP value represents the filter value for the telemetry packet.

[0038] The sending module is used to send telemetry data packets to the source server.

[0039] Fifthly, this application also provides a source server, including: a transmitter, a receiver, and a processor.

[0040] A transmitter used to send data packets to a target switch; the data packets include Differential Service Code Point (DSCP) values.

[0041] The receiver is used to receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on information from the target switch after determining that the DSCP value represents the filtering value of the telemetry packets.

[0042] The processor is used for congestion control based on telemetry data packets.

[0043] Sixthly, this application also provides a switch, including: a receiver, a processor, and a transmitter.

[0044] The receiver is used to receive data packets sent by the source server; the data packets include the Differential Service Code Point (DSCP) value.

[0045] The processor is used to generate telemetry data packets based on information from the switch, given that the DSCP value represents a filter value for the telemetry packet.

[0046] A transmitter is used to send telemetry data packets to the source server.

[0047] In a seventh aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the first and second aspects described above.

[0048] Eighthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the first and second aspects described above.

[0049] The aforementioned congestion control methods, devices, source servers, switches, storage media, and program products, by carrying DSCP values ​​in the transmitted data packets, enable the target switch to generate telemetry data packets based on the target switch's information when it receives the DSCP value as a filter value for telemetry packets, and then send the telemetry data packets to the source server. This allows the source server to perform congestion control based on the telemetry data packets. Compared to existing methods that add ECN tags to data packets, send ECN-tagged data packets to the destination server, and then have the destination server send ECN-tagged data packets to the source server, so that the source server avoids sending packets to the congested switch after receiving the ECN-tagged packets, thereby optimizing network traffic and reducing congestion, this application eliminates the need to continue sending data packets to the destination server when the target switch is congested, and also eliminates the need for the destination server to send data packets to the source server via the target switch. This reduces data transmission latency while avoiding switch congestion. Attached Figure Description

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

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

[0052] Figure 2 This is a flowchart illustrating a congestion control method in one embodiment;

[0053] Figure 3 This is a schematic diagram illustrating the effect of a congestion control method in one embodiment;

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

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

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

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

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

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

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

[0061] Figure 11 This is a system framework diagram of a congestion control method in one embodiment;

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

[0063] Figure 13 This is a block diagram of a congestion control device in another embodiment. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0065] During network communication, the source server sends packets to the destination server via a switch to achieve end-to-end network communication. If multiple source servers send packets to the destination server through a single switch during this process, it will cause switch congestion. Figure 1 As shown, server 1 (source server) sends a message to switch 4 through switch 1, and server 3 also sends a message to switch 4. As a result, the messages sent by server 1 and server 3 will cause congestion at switch 4, resulting in a congestion problem at switch 4.

[0066] Currently, the main method for reducing switch congestion is through Explicit Congestion Notification (ECN) tagging. This involves including an ECN tag in the packets sent by the congested switch to the destination server. The destination server then forwards a response packet with the ECN tag to the source server via the congested switch. Upon receiving the ECN-tagged packet, the source server avoids sending packets to the congested switch, thereby optimizing network traffic and reducing congestion. Please continue reading... Figure 1 When switch 4 is congested, it adds an ECN tag to the packets it sends. The packets carrying the ECN tag are then sent to server 4 via switch 2 and switch 5 in sequence. Server 4 processes the packets and then sends the processed packets with the ECN tag via switch 5, switch 2, switch 4, and switch 1 to server 1 in sequence. After receiving the processed packets with the ECN tag, server 1 avoids sending the packets to switch 4, which corresponds to the ECN tag, and instead sends the packets to server 4 via switch 1, switch 3, switch 2, and switch 5 to reduce the probability of switch congestion.

[0067] However, while the aforementioned methods for reducing switch congestion lower the probability of congestion to some extent, they also introduce higher data transmission latency. This application provides a data transmission method aimed at reducing data transmission latency while lowering the probability of switch congestion.

[0068] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0069] In one embodiment, such as Figure 2 As shown, a congestion control method is provided, which is applied to... Figure 1 Taking server 1 (i.e., the source server) as an example, the explanation includes the following steps:

[0070] S201. Send a data packet to the target switch; the data packet includes the Differential Service Code Point (DSCP) value.

[0071] The target switch can refer to any switch that the source server passes through during the process of sending data packets to the destination server. See [link to relevant documentation]. Figure 1 The target switch can be switch 1, switch 2, or switch 4.

[0072] It should be noted that the switches that the source server needs to pass through to send data packets to the destination server can be determined according to the preset path table. The preset path table includes the path information of which switches the source server uses to send data packets to the destination server, and any switch in the preset path table can be the destination switch.

[0073] Optionally, the data packet may also carry the identification information of the switch, so that the source server can send the data packet to the corresponding switch according to the switch identification information, and the switch determined according to the switch identification information is the destination switch.

[0074] Optionally, the data packets sent from the source server to the target switch also need to carry a Differentiated Services Code Point (DSCP) value. The DSCP value is information in the data packet used to identify the priority and quality of service level of network traffic. The DSCP value can also represent a filtered value for telemetry packets, allowing the switch to generate a corresponding telemetry data packet based on its own attribute and operational information when it receives a data packet representing a filtered telemetry packet. Similarly, the DSCP value can also represent a non-filtered value for telemetry packets, so that the switch does not need to generate a corresponding telemetry data packet when it receives a data packet representing a non-filtered telemetry packet.

[0075] In this embodiment, the source server can send a data packet carrying a DSCP value to the target switch, so that the target switch, after determining that the DSCP value of the data packet represents the filtering value of the telemetry packet, generates a telemetry data packet based on its own attribute information and operation information, and sends the telemetry data packet to the source server.

[0076] S202. Receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on the information of the target switch after determining that the DSCP value represents the filtering value of the telemetry packets.

[0077] The target switch information may include attribute information and operational information. Attribute information may include the target switch's identification information, the queue identification information of each output port of the target switch, the target switch's memory, computing resources, etc. Operational information may include the target switch's link utilization, the queue depth of each output port of the target switch, remaining memory, remaining computing resources, temperature, etc.

[0078] In this embodiment, after the target switch sends the telemetry data packet to the source server, the source server receives the telemetry data packet sent by the target switch.

[0079] Optionally, the DSCP value of the data packet can be set to two values, such as 0 and 1. When the DSCP value is 0, it represents the filtered value of the telemetry packet; when the DSCP value is 1, it represents the unfiltered value of the telemetry packet. The target switch will only generate a telemetry data packet based on its own information if the DSCP value represents the filtered value of the telemetry packet. For example, after receiving a data packet, the target switch can parse the data packet to obtain the DSCP value carried in the data packet, determine whether the DSCP value carried in the data packet represents the filtered value of the telemetry packet, and generate a telemetry data packet based on the target switch's information if the DSCP value carried in the data packet represents the filtered value of the telemetry packet.

[0080] Optionally, the DSCP value of the data packet can also be set to multiple values, such as 0, 1, 2, 3 and 4. When the DSCP value is 2, it represents the filtered value of the telemetry packet. When the DSCP value is 0, 1, 3 and 4, it represents the unfiltered value of the telemetry packet. Only when the DSCP value is 2 will the target switch generate telemetry data packets based on its own information.

[0081] Optionally, the generation method of telemetry data packets can also be described here. After the target switch receives the data packet sent by the source server, it parses the data packet to obtain the DSCP value carried in the data packet, and determines whether the DSCP value carried in the data packet is the filter value of the telemetry packet. If the DSCP value of the data packet is the filter value of the telemetry packet, the information of the target switch is added to the received data packet to generate a telemetry data packet, and the telemetry data packet is sent to the source server. Alternatively, if the DSCP value of the data packet is the filter value of the telemetry packet, the information of the target switch is directly used to generate a telemetry data packet, and the telemetry data packet is sent to the source server. Or, if the DSCP value of the data packet is the filter value of the telemetry packet, the information of the target switch is added to a new data packet to generate a telemetry data packet, and the telemetry data packet is sent to the source server.

[0082] It should be noted that when it is necessary to add the target switch's information to a data packet to generate a telemetry data packet, the target switch's information can be added to the data portion of the data packet, rather than the header portion.

[0083] S203. Perform congestion control based on telemetry data packets.

[0084] In this embodiment, after receiving the telemetry data packet sent by the target switch, the telemetry data packet can be parsed to obtain the target switch's attribute information and operating information. Based on the target switch's operating information, it can be determined whether the target switch is congested. If the target switch is congested, based on the target switch's attribute information, the next time the data packet is sent, the data packet is sent to another switch besides the target switch to achieve congestion control of the switch. Alternatively, if the target switch is not congested, the source server does not need to perform any congestion control.

[0085] Optionally, when the target switch's operational information includes its link utilization, the server determines whether the link utilization has reached a preset utilization threshold. If the link utilization reaches the preset threshold, the source server determines that the target switch is congested and sends the next data packet to other switches besides the target switch, thus achieving congestion control when the target switch is congested. Alternatively, when the target switch's operational information includes the queue depth of each output port, the server determines whether the queue depth of each output port has reached a preset queue depth. If the queue depth reaches the preset queue depth, the source server determines that the target switch is congested and sends the next data packet to other switches besides the target switch. The source server can send the next data packet to other switches besides the target switch to perform congestion control when the target switch is congested; or, when the target switch's operating information includes the target switch's link utilization and / or the queue depth of each output port of the target switch, it can determine whether the link utilization has reached a preset link utilization and / or whether the queue depth of each output port has reached a preset queue depth. If the link utilization reaches the preset link utilization and / or the queue depth reaches the preset queue depth, the source server determines that the target switch is congested and sends the next data packet to other switches besides the target switch to perform congestion control when the target switch is congested.

[0086] To further illustrate the effects of this application, see [link to relevant documentation]. Figure 3 Server 1 (the source server) sends a message to switch 4 via switch 1, and server 3 also sends a message to switch 4. This causes congestion at switch 4, as the messages from server 1 and server 3 both send packets. When switch 4 is congested, it generates telemetry data packets based on its own information and sends these packets to server 1 via switch 1 along the feedback path corresponding to path 1. (This process does not require...) Figure 1 Similarly, the message needs to be sent to server 4 sequentially via switch 2 and switch 5. Then server 4 processes the message and sends the processed message carrying the ECN tag back to server 1 sequentially via switch 5, switch 2, switch 4, and switch 1 (reducing the delay in congestion handling). After receiving the telemetry data packet, server 1 avoids sending the data packet to the target switch that generated the telemetry data packet, and instead sends the message to server 4 via switch 1, switch 3, switch 2, and switch 5 to reduce the probability of the switch experiencing congestion problems.

[0087] In this embodiment, by carrying a DSCP value in the transmitted data packet, the target switch, upon receiving the DSCP value as a filter value for the telemetry packet, generates a telemetry data packet based on the target switch's information and sends the telemetry data packet to the source server. This allows the source server to perform congestion control based on the telemetry data packet. Compared to existing methods that add an ECN tag to the data packet, send the ECN-tagged data packet to the destination server, and then have the destination server send the ECN-tagged data packet to the source server, thus preventing the source server from sending packets to the congested switch and optimizing network traffic and reducing congestion, this application eliminates the need to continue sending data packets to the destination server when the target switch is congested, and also eliminates the need for the destination server to send data packets to the source server via the target switch. This reduces data transmission latency while avoiding switch congestion.

[0088] In this embodiment, in the above Figure 2 Based on the illustrated embodiment, a detailed process for congestion control based on telemetry data packets will be explained. In one exemplary embodiment, such as Figure 4 As shown, the above S203 includes:

[0089] S301. Determine the congestion judgment strategy based on the business scenario corresponding to the data packet.

[0090] These business scenarios include low-latency sensitive scenarios, high-throughput scenarios, bandwidth sensitive scenarios, and burst traffic buffering scenarios. Different types of data packets correspond to different types of business scenarios, and different types of business scenarios correspond to different congestion control strategies.

[0091] In this embodiment, the corresponding business scenario is determined based on the type of data packet, and the corresponding congestion judgment strategy is determined based on the business scenario corresponding to the data packet.

[0092] S302. Perform congestion control based on telemetry data packets and congestion judgment strategies.

[0093] In this embodiment, after determining the congestion judgment strategy and receiving the telemetry data packet sent by the target switch, the telemetry data packet is parsed to obtain the parsing result. Based on the parsing result and the congestion judgment strategy, it is determined whether the target switch is congested. If the target switch is determined to be congested, the data packet is sent to other switches besides the target switch for congestion control. Alternatively, if the target switch is determined to be congested, the congestion status of the target switch in the preset path table is marked as congested. So that when the source server sends a data packet next time, the data packet is sent to the destination server based on a path in the preset path table other than the target switch for congestion control.

[0094] In this embodiment, different congestion judgment strategies are determined for different business scenarios, thereby achieving accurate congestion control under different business scenarios based on telemetry data packets and corresponding congestion judgment strategies. Compared with congestion control strategies that use the same congestion judgment strategy for different business scenarios, this application formulates different congestion judgment strategies for different business scenarios, thereby achieving accurate congestion control under different business scenarios.

[0095] In this embodiment, in the above Figure 4 Based on the illustrated embodiments, the detailed process of congestion control will be further explained and illustrated. In one exemplary embodiment, such as Figure 5 As shown, the above S302 includes:

[0096] S401. Parse the telemetry data packet to obtain the parsing result; the parsing result includes the target switch's attribute information and the target switch's operating information.

[0097] The attribute information includes the identification information of the target switch and the queue identification information of each output port of the target switch, while the operational information includes the link utilization of the target switch and the queue depth of each output port of the target switch.

[0098] In this embodiment, telemetry data packets can be parsed to obtain parsing results. Optionally, telemetry data packets can be parsed using graphical tools, command-line tools, or programmatic parsing. For example, the image tool Wireshark can be used to expand the telemetry data packets layer by layer and view the protocol fields of each layer to obtain parsing results. Alternatively, the command-line tools tcpdump or tshark can be used to quickly extract key fields using filters to obtain parsing results.

[0099] S402. Based on the parsing results and congestion judgment strategy, perform congestion control.

[0100] In this embodiment, after obtaining the attribute information and operation information of the target switch, it is possible to determine whether the target switch is congested based on the operation information and congestion judgment strategy. If the target switch is congested, packets are sent to other switches besides the target switch according to the attribute information of the target switch to perform congestion control.

[0101] Optionally, this embodiment further provides a method for congestion control based on parsing results and congestion judgment strategies, see [link to documentation]. Figure 6 The aforementioned S402 includes:

[0102] S4021. Based on the target switch's operating information and congestion judgment strategy, if it is determined that the target switch is in a congested state, query the preset path table according to the target switch's attribute information to determine the target path; the target path includes the target switch.

[0103] The preset path table records the transmission path of each data packet. For example, data packet 1 is sent from the source server and transmitted to the destination server via switch 2, switch 3 and switch 5. Data packet 1 is sent from the source server and transmitted to the destination server via switch 1, switch 3 and switch 4.

[0104] In this embodiment, after obtaining the parsing result, it is possible to determine whether the target switch is in a congested state based on the target switch's operating information and congestion judgment strategy in the parsing result. If it is determined that the target switch is in a congested state, the preset path table is queried based on the target switch's attribute information, and the path where the target switch is located is determined as the target path.

[0105] S4022. Mark the target path as congested in the preset path table.

[0106] In this embodiment, after determining the target path including the target switch, the target path can be marked as congested in the preset path table to obtain a new preset path table. In the next transmission of data packets, data packets are transmitted based on the non-target path according to the new preset path table to perform congestion control.

[0107] In this embodiment, by parsing telemetry data packets, the attribute information and operating information of the target switch are obtained. Based on the attribute information, operating information and congestion judgment strategy of the target switch, congestion control is performed, thereby reducing data transmission latency while avoiding switch congestion.

[0108] In this embodiment, in the above Figure 4 or Figure 5Based on the illustrated embodiments, the detailed process of determining the congestion judgment strategy according to the service scenario corresponding to the data packets will be further explained. In an exemplary embodiment, such as Figure 7 As shown, the above S301 includes:

[0109] S501. In the case of a latency-sensitive business scenario, the congestion judgment strategy includes: if the link utilization rate is greater than the first threshold, or the queue depth is greater than the second threshold, then the target switch is determined to be in a congested state.

[0110] The first threshold can be 70%, and the second threshold can be 50%.

[0111] In this embodiment, the service scenario corresponding to the data packet can be determined based on the fields carried in the data packet. If the service scenario corresponding to the data packet is determined to be a latency-sensitive service scenario, the congestion judgment strategy is determined as follows: if the link utilization is greater than the first threshold or the queue depth is greater than the second threshold, then the target switch is determined to be in a congested state.

[0112] S502. In the case of a throughput business scenario, the congestion judgment strategy includes: if the link utilization is greater than the third threshold and the queue depth is greater than the fourth threshold, then the target switch is determined to be in a congested state.

[0113] The third threshold can be 90%, and the fourth threshold can be 80%.

[0114] In this embodiment, the business scenario corresponding to the data packet can be determined based on the fields carried in the data packet. If the business scenario corresponding to the data packet is determined to be a high-throughput business scenario, the congestion judgment strategy is determined as follows: if the link utilization is greater than the third threshold and the queue depth is greater than the fourth threshold, then the target switch is determined to be in a congested state.

[0115] S503. In the case of a bandwidth-sensitive business scenario, the congestion judgment strategy includes: if the link utilization rate is greater than the fifth threshold, then the target switch is determined to be in a congested state.

[0116] The fifth threshold can be determined based on the specific circumstances of bandwidth-sensitive service scenarios, and this embodiment does not impose any restrictions on it.

[0117] In this embodiment, the service scenario corresponding to the data packet can be determined based on the fields carried in the data packet. If the service scenario corresponding to the data packet is determined to be a bandwidth-sensitive service scenario, the congestion judgment strategy is determined as follows: if the link utilization is greater than the fifth threshold, the target switch is determined to be in a congested state.

[0118] S504. In scenarios where the business scenario is a traffic buffering scenario, the congestion judgment strategy includes: if the queue depth is greater than the sixth threshold, then the target switch is determined to be in a congested state.

[0119] The sixth threshold can be determined based on the specific circumstances of the traffic buffering scenario, and this embodiment does not impose any restrictions on it.

[0120] In this embodiment, the business scenario corresponding to the data packet can be determined based on the fields carried in the data packet. If the business scenario corresponding to the data packet is determined to be a traffic buffering business scenario, the congestion judgment strategy is determined as follows: if the queue depth is greater than the sixth threshold, the target switch is determined to be in a congested state.

[0121] In this embodiment, different congestion judgment strategies are determined for different business scenarios, thereby achieving accurate congestion control under different business scenarios based on telemetry data packets and corresponding congestion judgment strategies. Compared with congestion control strategies that use the same congestion judgment strategy for different business scenarios, this application formulates different congestion judgment strategies for different business scenarios, thereby achieving accurate congestion control under different business scenarios.

[0122] In one embodiment, such as Figure 8 As shown, a congestion control method is provided, which is applied to... Figure 1 Taking the switch in the example, the explanation includes the following steps:

[0123] S601, Receive data packets sent by the source server; the data packets include the Differential Service Code Point (DSCP) value.

[0124] In this embodiment, the data packets sent from the source server to the switch need to carry a DSCP value. The DSCP value is information in the data packet used to identify the priority and quality of service level of network traffic. The DSCP value can also represent the filtering value of the telemetry packet, so that when the switch receives a data packet representing the filtering value of the telemetry packet, it can generate a corresponding telemetry data packet based on the switch's own attribute information and operating information. Similarly, the DSCP value can also represent the non-filtered value of the telemetry packet, so that when the switch receives a data packet representing the non-filtered value of the telemetry packet, it does not need to generate a corresponding telemetry data packet.

[0125] In this embodiment, the source server can send data packets carrying DSCP values ​​to the switch so that the switch can receive the data packets sent by the source server.

[0126] S602. Given that the DSCP value of the data packet represents the filtering value of the telemetry packet, generate a telemetry data packet based on the information from the switch.

[0127] In this embodiment, after receiving the data packet sent by the source server, the data packet is parsed to obtain the DSCP value carried in the data packet. If it is determined that the DSCP value of the data packet represents the filtering value of the telemetry packet, a telemetry data packet is generated based on its own attribute information and operation information, and the telemetry data packet is sent to the source server.

[0128] The attribute information may include the target switch's identification information, the queue identification information of each output port of the target switch, the target switch's memory, computing resources, etc., while the operation information may include the target switch's link utilization, the queue depth of each output port of the target switch, remaining memory, remaining computing resources, temperature, etc.

[0129] In this embodiment, after the target switch sends the telemetry data packet to the source server, the source server receives the telemetry data packet sent by the target switch.

[0130] Optionally, the DSCP value of the data packet can be set to two values, such as 0 and 1. When the DSCP value is 0, it represents the filtered value of the telemetry packet; when the DSCP value is 1, it represents the unfiltered value of the telemetry packet. The target switch will only generate a telemetry data packet based on its own information if the DSCP value represents the filtered value of the telemetry packet. For example, after receiving a data packet, the target switch can parse the data packet to obtain the DSCP value carried in the data packet, determine whether the DSCP value carried in the data packet represents the filtered value of the telemetry packet, and generate a telemetry data packet based on the target switch's information if the DSCP value carried in the data packet represents the filtered value of the telemetry packet.

[0131] Optionally, the DSCP value of the data packet can also be set to multiple values, such as 0, 1, 2, 3 and 4. When the DSCP value is 2, it represents the filtered value of the telemetry packet. When the DSCP value is 0, 1, 3 and 4, it represents the unfiltered value of the telemetry packet. Only when the DSCP value is 2 will the target switch generate telemetry data packets based on its own information.

[0132] Optionally, the generation method of telemetry data packets can also be described here. After the target switch receives the data packet sent by the source server, it parses the data packet to obtain the DSCP value carried in the data packet, and determines whether the DSCP value carried in the data packet is the filter value of the telemetry packet. If the DSCP value of the data packet is the filter value of the telemetry packet, the information of the target switch is added to the received data packet to generate a telemetry data packet, and the telemetry data packet is sent to the source server. Alternatively, if the DSCP value of the data packet is the filter value of the telemetry packet, the information of the target switch is directly used to generate a telemetry data packet, and the telemetry data packet is sent to the source server. Or, if the DSCP value of the data packet is the filter value of the telemetry packet, the information of the target switch is added to a new data packet to generate a telemetry data packet, and the telemetry data packet is sent to the source server.

[0133] It should be noted that when it is necessary to add the target switch's information to a data packet to generate a telemetry data packet, the target switch's information can be added to the data portion of the data packet, rather than the header portion.

[0134] S603. Send the telemetry data packet to the source server.

[0135] In this embodiment, after receiving the telemetry data packet sent by the target switch, the telemetry data packet can be parsed to obtain the target switch's attribute information and operating information. Based on the target switch's operating information, it can be determined whether the target switch is congested. If the target switch is congested, based on the target switch's attribute information, the next time the data packet is sent, the data packet is sent to another switch besides the target switch to achieve congestion control of the switch. Alternatively, if the target switch is not congested, the source server does not need to perform any congestion control.

[0136] Optionally, when the target switch's operational information includes its link utilization, the server determines whether the link utilization has reached a preset utilization threshold. If the link utilization reaches the preset threshold, the source server determines that the target switch is congested and sends the next data packet to other switches besides the target switch, thus achieving congestion control when the target switch is congested. Alternatively, when the target switch's operational information includes the queue depth of each output port, the server determines whether the queue depth of each output port has reached a preset queue depth. If the queue depth reaches the preset queue depth, the source server determines that the target switch is congested and sends the next data packet to other switches besides the target switch. The source server can send the next data packet to other switches besides the target switch to perform congestion control when the target switch is congested; or, when the target switch's operating information includes the target switch's link utilization and / or the queue depth of each output port of the target switch, it can determine whether the link utilization has reached a preset link utilization and / or whether the queue depth of each output port has reached a preset queue depth. If the link utilization reaches the preset link utilization and / or the queue depth reaches the preset queue depth, the source server determines that the target switch is congested and sends the next data packet to other switches besides the target switch to perform congestion control when the target switch is congested.

[0137] In this embodiment, by carrying a DSCP value in the transmitted data packet, the target switch, upon receiving the DSCP value as a filter value for the telemetry packet, generates a telemetry data packet based on the target switch's information and sends the telemetry data packet to the source server. This allows the source server to perform congestion control based on the telemetry data packet. Compared to existing methods that add an ECN tag to the data packet, send the ECN-tagged data packet to the destination server, and then have the destination server send the ECN-tagged data packet to the source server, thus preventing the source server from sending packets to the congested switch and optimizing network traffic and reducing congestion, this application eliminates the need to continue sending data packets to the destination server when the target switch is congested, and also eliminates the need for the destination server to send data packets to the source server via the target switch. This reduces data transmission latency while avoiding switch congestion.

[0138] In this embodiment, in the above Figure 8 Based on the illustrated embodiment, the detailed process of generating telemetry data packets will be further explained. In one exemplary embodiment, such as Figure 9 As shown, the above S602 includes:

[0139] S701. Sample the target data packet based on the preset message sampling rate to obtain the sampled data packet; the target data packet is a data packet whose DSCP value represents the filtered value of the telemetry packet.

[0140] The preset packet sampling rate can be pre-set in the switch and is used to filter the received data packets. The preset packet sampling rate can be 1:1000 or 1:100.

[0141] In this embodiment, after determining that the data packet is a data packet whose DSCP value represents the filtered value of the telemetry packet, the data packet whose DSCP value represents the filtered value of the telemetry packet can be sampled based on a preset message sampling rate to obtain the sampled data packet.

[0142] S702. Generate telemetry data packets based on the sampled data packets and information from the switch.

[0143] In this embodiment, after obtaining the sampled data packets, telemetry data packets can be generated based on the sampled data packets and the information of the switch.

[0144] For example, if there are 1000 data packets whose DSCP values ​​represent the filtered values ​​of telemetry packets sent by the source server, then based on a preset message sampling rate of 1:100, 10 data packets whose DSCP values ​​represent the filtered values ​​of telemetry packets and the switch information are extracted to generate 10 telemetry data packets, and these 10 telemetry data packets are sent to the source server.

[0145] It should be noted that during periods of high congestion, reducing the sampling rate (e.g., 1:1000) can reduce reverse bandwidth usage; while during periods of low load, increasing the sampling rate (e.g., 1:100) can enhance sensing sensitivity.

[0146] Under the same congestion conditions, the target generates telemetry data packets at a sampling rate of 1:1000 and sends the telemetry data packets to the source server. The source server then switches to another path to send data packets to the destination server. This reduces the switching latency to 1ms, the bandwidth utilization to 89.1%, and the control traffic to 0.15%. When the sampling rate is adjusted to 1:100 and the experiment is repeated, it is found that the switching latency is reduced to 0.87ms (a decrease of 13%), the bandwidth utilization to 91.4% (an increase of 2.3%), and the control traffic to 0.8% (less than the 1% safety threshold).

[0147] In this embodiment, data packets whose DSCP values ​​represent the filter values ​​of telemetry packets are sampled by a preset message sampling rate, and then telemetry data packets are generated based on the sampled data packets. Compared with the method of directly generating telemetry data packets based on data packets whose DSCP values ​​represent the filter values ​​of telemetry packets, this application can generate fewer telemetry data packets, and thus send a small number of telemetry data packets to the source server quickly, avoiding congestion again, thereby improving the efficiency of congestion control.

[0148] In one embodiment, such as Figure 10 As shown, a congestion control method is also provided, including:

[0149] T1 (Source Server) sends a data packet to the target switch; the data packet includes the Differential Service Code Point (DSCP) value.

[0150] T2 (Target Switch) receives data packets sent by the source server;

[0151] T3. Given that the DSCP value of the data packet represents the filtering value of the telemetry packet, the target data packet is sampled based on the preset message sampling rate to obtain the sampled data packet; the target data packet is the data packet whose DSCP value represents the filtering value of the telemetry packet.

[0152] T4. Generate telemetry data packets based on the sampled data packets and information from the switch;

[0153] T5. Send the telemetry data packet to the source server;

[0154] T6 (Source server) receives telemetry data packets sent by the target switch;

[0155] T7. Determine the congestion judgment strategy based on the business scenario corresponding to the data packet;

[0156] T8. Parse the telemetry data packets to obtain the parsing results; the parsing results include the target switch's attribute information and the target switch's operating information;

[0157] T9. Based on the target switch's operating information and congestion judgment strategy, if it is determined that the target switch is in a congested state, query the preset path table according to the target switch's attribute information to determine the target path; the target path includes the target switch.

[0158] T10. Mark the target path as congested in the preset path table.

[0159] It should be noted that the descriptions of T1-T10 above can be found in the relevant descriptions in the above embodiments, and their effects are similar, so they will not be repeated here.

[0160] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0161] In one embodiment, such as Figure 11 As shown, an implementation architecture for a congestion control method is also provided, including: a source server, at least one switch, and a destination server. Before sending a data packet, the source server receives packet transmission path requests from other devices. At this time, the source server queries a path table, determines the target path from the path table, and sends a data packet carrying a DSCP value to the switch based on the target path. After receiving the data packet carrying the DSCP value, the switch determines whether the DSCP value is a filtering value for telemetry packets. If it determines that the DSCP value represents a filtering value for telemetry packets, it further determines the target switch's identification information, link utilization, and queues at each output port. The identification information and queue depth of each output port are used to generate telemetry data packets, which are then returned to the source server. This allows the source server to determine whether the target switch is congested based on its link utilization and the queue depth of each output port. If the target switch is congested, the source server marks it in the path table based on its identification information and the queue identification information of each output port. This enables the source server to send the data packets to other switches besides the target switch the next time it sends a data packet, thus achieving congestion control of the switch. Alternatively, if the target switch is not congested, the source server does not need to perform any congestion control.

[0162] Based on the same inventive concept, this application also provides a congestion control device for implementing the congestion control method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the congestion control device provided below can be found in the limitations of the congestion control method described above, and will not be repeated here.

[0163] In one exemplary embodiment, such as Figure 12As shown, a congestion control device is provided, comprising: a transmitting module 10, a receiving module 11, and a control module 12, wherein:

[0164] The sending module 10 is used to send data packets to the target switch; the data packets include the Differential Service Code Point (DSCP) value.

[0165] The receiving module 11 is used to receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on the information of the target switch after determining that the DSCP value represents the filtering value of the telemetry packet.

[0166] Control module 12 is used for congestion control based on telemetry data packets.

[0167] In an exemplary embodiment, the control module 12 includes:

[0168] The determination unit is specifically used to determine the congestion judgment strategy based on the business scenario corresponding to the data packet;

[0169] The control unit is specifically used to perform congestion control based on telemetry data packets and congestion assessment strategies.

[0170] In an exemplary embodiment, the control unit is further configured to parse telemetry data packets to obtain parsing results; the parsing results include attribute information of the target switch and operating information of the target switch; and to perform congestion control based on the parsing results and congestion judgment strategy.

[0171] In an exemplary embodiment, the control unit is further configured to, based on the target switch's operating information and congestion judgment strategy, determine the target switch as it is in a congested state by querying a preset path table according to the target switch's attribute information to determine the target path; the target path includes the target switch; and the target path is marked as congested in the preset path table.

[0172] In an exemplary embodiment, the operating information of the target switch includes link utilization and queue depth of each output port. Specifically, the determining unit is further configured to determine the congestion judgment strategy as follows: In a latency-sensitive service scenario, if the link utilization is greater than a first threshold, or the queue depth is greater than a second threshold, then the target switch is determined to be in a congested state; in a throughput-sensitive service scenario, if the link utilization is greater than a third threshold and the queue depth is greater than a fourth threshold, then the target switch is determined to be in a congested state; in a bandwidth-sensitive service scenario, if the link utilization is greater than a fifth threshold, then the target switch is determined to be in a congested state; and in a traffic buffering service scenario, if the queue depth is greater than a sixth threshold, then the target switch is determined to be in a congested state.

[0173] In one exemplary embodiment, such as Figure 13 As shown, a congestion control device is provided, comprising: a receiving module 20, a generating module 21, and a sending module 22, wherein:

[0174] The receiving module 20 is used to receive data packets sent by the source server; the data packets include Differential Service Code Point (DSCP) values;

[0175] The generation module 21 is used to generate telemetry data packets based on information from the switch, given that the DSCP value of the data packet represents the filtering value of the telemetry packet.

[0176] The sending module 22 is used to send telemetry data packets to the source server.

[0177] In an exemplary embodiment, the generation module 21 described above includes:

[0178] The acquisition unit is specifically used to sample the target data packet based on a preset message sampling rate to obtain the sampled data packet; the target data packet is a data packet whose DSCP value represents the filtered value of the telemetry packet.

[0179] The generation unit is specifically used to generate telemetry data packets based on the sampled data packets and information from the switch.

[0180] The modules in the aforementioned congestion control device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0181] In one exemplary embodiment, a source server is provided, including: a transmitter, a receiver, and a processor.

[0182] A transmitter used to send data packets to a target switch; the data packets include Differential Service Code Point (DSCP) values.

[0183] The receiver is used to receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on information from the target switch after determining that the DSCP value represents the filtering value of the telemetry packets.

[0184] The processor is used for congestion control based on telemetry data packets.

[0185] In one exemplary embodiment, a switch is provided, including: a receiver, a processor, and a transmitter.

[0186] The receiver is used to receive data packets sent by the source server; the data packets include the Differential Service Code Point (DSCP) value.

[0187] The processor is used to generate telemetry data packets based on information from the switch, given that the DSCP value represents a filter value for the telemetry packet.

[0188] A transmitter is used to send telemetry data packets to the source server.

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

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

[0191] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0192] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0193] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A congestion control method, characterized in that, Applied to a source server, the method includes: Send a data packet to the target switch; the data packet includes a Differential Service Code Point (DSCP) value. Receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on information from the target switch after determining that the DSCP value represents the filtering value of the telemetry packets; Congestion control is performed based on the telemetry data packets.

2. The method according to claim 1, characterized in that, The congestion control based on the telemetry data packets includes: Based on the business scenario corresponding to the data packet, determine the congestion judgment strategy; Congestion control is performed based on the telemetry data packets and the congestion assessment strategy.

3. The method according to claim 2, characterized in that, The congestion control based on the telemetry data packets and the congestion assessment strategy includes: The telemetry data packet is parsed to obtain the parsing result; the parsing result includes the attribute information of the target switch and the operating information of the target switch; Congestion control is performed based on the parsing results and the congestion judgment strategy.

4. The method according to claim 3, characterized in that, The congestion control based on the parsing results and the congestion judgment strategy includes: Based on the operating information of the target switch and the congestion judgment strategy, if it is determined that the target switch is in a congested state, a preset path table is queried according to the attribute information of the target switch to determine the target path; the target path includes the target switch. The target path is marked as congested in the preset path table.

5. The method according to claim 3 or 4, characterized in that, The target switch's operational information includes link utilization and queue depth for each output port. The congestion assessment strategy, determined based on the service scenario corresponding to the data packet, includes: When the business scenario is a latency-sensitive business scenario, the congestion judgment strategy is determined as follows: if the link utilization is greater than a first threshold, or the queue depth is greater than a second threshold, then the target switch is determined to be in a congested state. When the business scenario is a throughput business scenario, the congestion judgment strategy is determined as follows: if the link utilization is greater than the third threshold and the queue depth is greater than the fourth threshold, then the target switch is determined to be in a congested state. In the case where the business scenario is a bandwidth-sensitive scenario, the congestion judgment strategy is determined as follows: if the link utilization rate is greater than the fifth threshold, then the target switch is determined to be in a congested state. In a scenario where the business scenario is a traffic buffering scenario, the congestion judgment strategy is determined as follows: if the queue depth is greater than the sixth threshold, then the target switch is determined to be in a congested state.

6. A congestion control method, characterized in that, Applied to a switch, the method includes: Receive data packets sent by the source server; the data packets include Differential Service Code Point (DSCP) values; If it is determined that the DSCP value of the data packet represents the filtering value of the telemetry packet, a telemetry data packet is generated based on the information of the switch; The telemetry data packet is sent to the source server.

7. The method according to claim 6, characterized in that, The generation of telemetry data packets based on the information from the switch includes: The target data packet is sampled based on a preset message sampling rate to obtain the sampled data packet; the target data packet is the data packet whose DSCP value represents the filtered value of the telemetry packet. The telemetry data packet is generated based on the sampled data packet and the information from the switch.

8. A congestion control device, characterized in that, Applied to a source server, the device includes: The sending module is used to send data packets to the target switch; the data packets include Differential Service Code Point (DSCP) values. A receiving module is used to receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on information from the target switch after determining that the DSCP value represents the filtering value of the telemetry packet. The control module is used to perform congestion control based on the telemetry data packets.

9. A congestion control device, characterized in that, Applied to a switch, the device includes: A receiving module is used to receive data packets sent by a source server; the data packets include Differential Service Code Point (DSCP) values. The generation module is used to generate telemetry data packets based on the information of the switch, given that the DSCP value represents a filter value for the telemetry packet. The sending module is used to send the telemetry data packet to the source server.

10. A source server, characterized in that, The source server includes: a transmitter, a receiver, and a processor. The transmitter is used to send data packets to the target switch; the data packets include Differential Service Code Point (DSCP) values. The receiver is used to receive telemetry data packets sent by the target switch; the telemetry data packets are generated by the target switch based on information from the target switch after determining that the DSCP value represents the filtering value of the telemetry packet. The processor is used to perform congestion control based on the telemetry data packets.

11. A switch, characterized in that, The switch includes: a receiver, a processor, and a transmitter. The receiver is used to receive data packets sent by the source server; the data packets include Differential Service Code Point (DSCP) values. The processor is configured to generate telemetry data packets based on information from the switch, provided that the DSCP value represents a filter value for the telemetry packet. The transmitter is used to send the telemetry data packet to the source server.

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

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • Data center congestion control method and system based on path switching perception

    CN114679408A

  • Data center lossless network congestion control method, device, equipment and medium

    CN115460156A

  • Congestion control method, system and device, communication equipment and storage medium

    CN116545936A

  • Telemetry-Based Load-Balanced Fine-Grained Adaptive Routing in High-Performance System Interconnect

    US20220417163A1