Network load based data center congestion control method and system

Abstract

The application provides a network load based congestion control method and system in a data center, the method comprising: receiving a data packet from a switch and detecting whether the data packet is marked with a congestion mark; if the data packet is marked with the congestion mark, counting the total amount of data packets received by a receiving end in a preset time as network load; adding information of the network load and congestion mark information of the data packet to an ACK packet fed back to a sending end, so that the sending end can adjust the size of a sending window to the total amount of data packets received by the receiving end based on the congestion mark and network load information in the received ACK packet, to relieve congestion.

Description

Technical Field

[0001] This invention relates to the field of data center network technology, and in particular to a method and system for congestion control within a data center based on network load. Background Technology

[0002] Over the past decade, driven by the demands of popular network applications (such as search, online retail, and cloud computing), data centers have been established and developed globally at an unprecedented speed and scale. In particular, to ensure data connectivity and improve user experience, transport layer protocols in data center networks have attracted widespread attention from academia and industry. However, data center networks differ from the traditional Internet in several ways (such as a single control requirement and homogeneous network architecture), which presents both significant opportunities and challenges for the design of transport layer protocols in data center networks, leading to the design and proposal of a series of corresponding transport protocols.

[0003] Data centers typically utilize commercial equipment to interconnect servers and switches through carefully designed networks, thereby achieving high-speed computing and massive storage needs in a more economical and convenient way. Compared to complex, variable, and not entirely controllable heterogeneous networks like the Internet, data center networks are homogeneous network environments within a single autonomous system (AS). A single AS means that the end hosts, their network protocols, and the network service requirements of their applications are relatively controllable and predictable. Homogeneity is manifested in the regularity of the data center network topology (predictable round-trip times (RTT) and relatively consistent link bandwidth). These characteristics also bring many opportunities for the design of transport layer protocols; for example, devices within the data center exhibit relatively consistent congestion signals, and all devices within the topology are controllable.

[0004] Transport layer protocols aim to provide applications with high-throughput, low-latency network data transmission services. Transport layer protocols include connectionless best-effort protocols, represented by the User Datagram Protocol (UDP); and connection-oriented reliable transport protocols, represented by the Transmission Control Protocol (TCP). In most network scenarios, the transport protocols used at the application layer are primarily connection-oriented reliable transport protocols. Congestion control protocols are a key focus of transport layer protocol research.

[0005] Over the years, numerous congestion control protocols have been proposed. Early on, within the context of the Internet, there were improvements to the TCP protocol such as TCP Tahoe, TCP Reno, and TCP Vegas. However, these solutions were all based on the core principles of the TCP protocol, utilizing packet loss signals within the network as congestion indicators. By the time the sender detected packet loss, the network typically already had significant congestion. On the other hand, besides using packet loss as a congestion indicator, data centers possess a richer array of congestion signals (some of which are unavailable on the Internet or exhibit significant fluctuations). These include Explicit Congestion Notification (ECN) flags from switches, end-to-end RTT latency, and Inband Network Telemetry (INT). By using these signals, the sender can more quickly assess network congestion and adjust its speed accordingly to reduce packet queuing.

[0006] In recent years, several more efficient congestion control protocols have been proposed, many of which employ the aforementioned congestion signals to better adapt to data center network environments. Examples include reactive congestion control mechanisms such as Data Center Quantized Congestion Notification (DCQCN), Timely, and High Precision Congestion Control (HPCC), and proactive congestion control mechanisms such as ExpressPass and Homa. However, the congestion signals in reactive congestion control mechanisms are too slow to respond to congestion and cannot support complex measurement functions; proactive congestion control mechanisms can only handle congestion when the network topology convergence ratio is 1 and cannot detect congestion occurring within the network.

[0007] Therefore, there is an urgent need for a congestion control method within data centers to control and mitigate congestion in data center networks. Summary of the Invention

[0008] In view of this, embodiments of the present invention provide a data center congestion control method and system based on network load measurement at the receiving end. By adjusting the size of the sending window through window control, the length of the switch port queue can be reduced more quickly and effectively to alleviate network congestion.

[0009] The first aspect of the present invention provides a congestion control method within a data center based on network load, the method comprising the following steps:

[0010] Receive data packets from the switch and detect whether the data packets have a congestion flag; if the data packets have a congestion flag, count the total number of data packets received by the receiver within a preset time as the network load;

[0011] The network load information and the congestion flag information of the data packets are added to the acknowledgment (ACK) message sent back to the sender, so that the sender can adjust the size of the sending window according to the total number of data packets received by the receiver based on the congestion flag and network load information in the received ACK message, thereby alleviating congestion.

[0012] In some embodiments of the present invention, the network load includes bottleneck link load and receiver link load;

[0013] The receiving end link load is the total number of data packets received by the receiving end port within a preset time.

[0014] The bottleneck link load is the total number of data packets received at the receiving end of the flow passing through the bottleneck link within a preset time.

[0015] The bottleneck link is either a link between switches or a link between an edge switch and a receiving end.

[0016] In some embodiments of the present invention, when the bottleneck link is a link between switches, the bottleneck link load is the total number of data packets of the flow received at the receiving end within a preset time.

[0017] When the bottleneck link is the link between the edge switch and the receiver, the bottleneck link load is the total number of data packets of the flow received at the receiver within a preset time.

[0018] The preset time is the round-trip time of a data packet.

[0019] In some embodiments of the present invention, adding the network load information and the congestion marking information of the data packets to the ACK packet fed back to the sender, so that the sender can adjust the size of the sending window according to the congestion marking and network load information in the received ACK packet to the total number of data packets received by the receiver, thereby alleviating congestion, includes:

[0020] By statistically analyzing the receiving rate and using the product of the rate and time, the receiving rate is converted into the total number of received data packets, so that the sending end can adjust the size of the sending window to the total number of data packets, thereby alleviating congestion.

[0021] Wherein, the bottleneck link load rate is the rate at which the receiving end receives the stream; the receiving end link load rate is the total rate at which the receiving end port receives data packets.

[0022] In some embodiments of the present invention, adding the network load information and the congestion marking information of the data packets to the ACK message fed back to the sender includes:

[0023] Based on the statistical network load, the network load information is added to the ACK message sent back to the sender via the kernel protocol stack;

[0024] Based on the congestion marking of data packets, the flag bits of the detected congestion marking are added to the ACK message sent back to the sender.

[0025] A second aspect of the present invention provides a congestion control method within a data center based on network load, the method comprising the following steps:

[0026] The system sends data packets from the data center network to the switch via a sending window, receives ACK packets from the receiving end, and determines whether the ACK packets carry a congestion flag.

[0027] If the received ACK message contains a congestion flag, the size of the sending window is adjusted to the size of the congested link load based on the congestion flag information and load network information in the returned ACK message, thereby alleviating congestion.

[0028] The congestion link load size is the total number of data packets received by the corresponding receiver.

[0029] In some embodiments of the present invention, the method further includes: after the data packet sent by the sending end arrives at the switch, the switch determines whether the queue length of the data packet exceeds a threshold.

[0030] If the queue length of the data packet exceeds a threshold, the switch marks the data packet as congested and sends the congestion-marked data packet to the receiving end.

[0031] In some embodiments of the present invention, the method further includes: when the ACK message received by the sending end does not carry congestion information, the sending end will increase the window to use the idle bandwidth;

[0032] The size of the sending window is the number of data packets sent by the sender but for which no ACK message has been received.

[0033] Another aspect of the present invention provides a data center congestion control system based on receiving end measurement of network load. The system includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the data center congestion control method described in the first aspect above.

[0034] Another aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data center congestion control method as described above.

[0035] This invention provides a data center congestion control method and system based on network load. It can determine whether data center network congestion has occurred by detecting whether received data packets carry congestion markers at the receiving end. Based on the detected congestion markers, it calculates the total number of data packets received by the receiving end and uses this total number of data packets as the network load of the data center network. It can add network load information and congestion marker information to ACK packets and send the ACK packets to the sending end. This allows the sending end to adjust the size of its sending window to match the total number of data packets received by the receiving end based on the congestion markers and network load information in the received ACK packets, thus reducing the switch port queue length more quickly and effectively to alleviate congestion.

[0036] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0037] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0038] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings:

[0039] Figure 1 This is a flowchart illustrating the DCQCN control protocol.

[0040] Figure 2 This is a flowchart illustrating the ExpressPass control protocol.

[0041] Figure 3 This is a flowchart illustrating the Homa control protocol.

[0042] Figure 4 This is an overall view of an embodiment of the present invention.

[0043] Figure 5 This is a schematic diagram of a data center congestion control method based on network load executed by the receiving end in one embodiment of the present invention.

[0044] Figure 6 This is a diagram of a data center network architecture.

[0045] Figure 7 This is a schematic diagram of a data center congestion control method based on network load executed by the sending end in one embodiment of the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0047] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0048] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0049] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0050] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0051] In recent years, several more efficient congestion control protocols have been proposed, including reactive congestion control protocols. Reactive congestion control protocols are algorithms where the sending end adjusts the rate based on congestion signals. A representative reactive congestion control protocol is described below:

[0052] like Figure 1 The diagram illustrates the DCQCN control protocol flow. DCQCN uses ECN signals at the switch. When the switch detects that the queue length of a corresponding port exceeds a certain threshold, it adds an ECN marker to the packet header. Upon receiving a packet with the ECN marker, the receiver sends a Congestion Notification Packet (CNP) to the corresponding sender. After receiving the CNP packet, the sender adjusts its transmission rate to reduce the queue length on the switch port.

[0053] Timely uses the RTT (Round-Trip Time) signal as a congestion indicator. Data center networks have a more uniform topology than the Internet, so the RTT fluctuation of each data packet is smaller. By measuring the difference between the RTT at the endpoint and the baseline RTT, the degree of congestion within the network can be obtained, and the transmission rate can be adjusted accordingly.

[0054] HPCC uses INT technology to add information such as the port queue and port rate of each switch to the packet header as it passes through. When the packet is sent back to the sender, the sender calculates the link utilization based on the link information carried in the packet and adjusts the transmission rate accordingly.

[0055] However, reactive congestion control protocols have the following problems:

[0056] (1) Existing reactive congestion control protocols rely on congestion signals to respond to congestion. However, congestion signals can only be generated when the queue accumulates to a certain extent, and the existing congestion signals are too slow to respond to congestion.

[0057] (2) In order to avoid excessive growth, existing responsive congestion control algorithms usually adopt multiple rounds of additive increase. That is, after a flow ends, the remaining flow needs to go through multiple rounds of convergence before it can re-occupy the idle bandwidth, thus slowing down the convergence speed.

[0058] (3) Some responsive congestion control algorithms, such as HPCC, use intranet information such as INT to converge at a more suitable parameter rate, but this brings great difficulties to the deployment of the algorithm because the existing data center switches have limited functions and most cannot support complex measurement functions.

[0059] Furthermore, the INT measurement function is unavailable in cloud data center scenarios.

[0060] In addition to the aforementioned reactive congestion control protocols, several proactive congestion control protocols have been proposed in recent years. Proactive congestion control protocols control data packet transmission by actively sending signaling (credit) packets from the receiver to the sender, thereby reducing network congestion. Representative proactive congestion control protocols are described below:

[0061] like Figure 2 The diagram shows the flow of the ExpressPass control protocol. The ExpressPass sender sends data packets to the switch within the first RTT (Round-Trip Time). Subsequently, the receiver continuously sends signaling packets to the sender to control the transmission of data packets. The receiver adjusts the transmission rate of signaling packets based on the packet loss situation at the switch.

[0062] like Figure 3The diagram illustrates the flow of the Homa control protocol. During the first RTT (Round-Trip Time), the Homa sender transmits unscheduled data packets to avoid wasting bandwidth. Subsequently, upon receiving the unscheduled packets, the receiver sends signaling packets to the sender. Once the sender receives the signaling packets, it sends scheduled data packets to the receiver. Furthermore, Homa employs a multi-priority queuing scheme at the switch to degrade flow completion time.

[0063] However, proactive congestion control protocols also have some problems, as described below:

[0064] (1) Some proactive congestion control algorithms require the first RTT to send credit signaling packets, which wastes the bandwidth of the first RTT. However, as data center link bandwidth increases, more and more flows can be sent within one RTT, and this algorithm greatly reduces the flow completion time;

[0065] (2) Some proactive congestion control algorithms send data packets directly within the first RTT, which can cause incast problems, resulting in a large backlog of data packets at the switch. To address this issue, some algorithms employ a multi-priority queue approach at the switch, prioritizing the forwarding of higher-priority data packets. However, this presents two problems. Firstly, priority queues on cloud data center switches are typically used to differentiate data packets for different services, and a switch generally only has eight priority queues. Secondly, using priorities requires the sender to know the flow size in advance, which is unavailable in most application scenarios.

[0066] (3) Some active congestion control algorithms can only handle congestion when the network topology convergence ratio is 1. When the network topology convergence ratio is greater than 1, the performance of the algorithm will be affected. This is because active congestion control algorithms detect congestion at the receiving end and cannot detect congestion occurring within the network.

[0067] To address the shortcomings of existing reactive congestion control algorithms, such as slow response and convergence, and the limitations of proactive congestion control algorithms, such as insufficient bandwidth utilization and reliance on underlying network support, this invention proposes a data center congestion control method and system based on network load. This method determines whether data center network congestion has occurred by detecting whether received data packets carry congestion markers at the receiving end. Based on the detected congestion markers, it calculates the total number of data packets received by the receiving end and uses this total number of data packets as the network load of the data center network. Furthermore, it adds network load information and congestion marker information to ACK packets and sends these ACK packets to the sending end. This allows the sending end to adjust the size of its sending window according to the congestion markers and network load information in the received ACK packets, thereby more quickly and effectively reducing switch port queue length and alleviating congestion.

[0068] Figure 4 The diagram shows the overall solution of this invention. At the sending end, this invention controls the total number of data packets within the network through window control. At the switch, it uses ECN marking; when the switch detects that the queue length exceeds a threshold Q... threshold Subsequently, ECN tags are added to arriving data packets. This tagging method allows for the acquisition of congestion information within the network. At the receiving end, network load is measured, including the load of bottleneck links and the load of the receiving link. The receiving end then adds this information to the ACK packet and returns it to the sending end. The above window control method maintains a sending window at the sending end, limiting the number of data packets within the network (similar to the sending window in TCP). The number of data packets within the network refers to packets that the sending end has sent but have not yet received an ACK. The sending end limits the total number of data packets within the network by changing the window size, thereby achieving congestion control.

[0069] Figure 5 The figure shows a schematic diagram of a data center congestion control method based on network load executed by the receiving end in an embodiment of the present invention. As shown in the figure, the data center congestion control method based on network load includes:

[0070] Step S110: Receive data packets from the switch and detect whether the data packets have a congestion flag; if the data packets have a congestion flag, count the total number of data packets received by the receiving end within a preset time as the network load.

[0071] In one embodiment of the present invention, an ECN marking scheme is deployed at the switch. Specifically, a threshold is set at the switch. When the switch detects that the length of the data packet queue flowing through the switch exceeds the threshold, the data packet is marked with an ECN. This ECN marking modifies the DSCP bit in the data packet header, and the switch then sends all data packets to the receiving end. The present invention does not limit the setting of the threshold.

[0072] In one embodiment of the present invention, the receiving end receives all data packets from the switch and checks whether the header of all received data packets carries an ECN tag. If an ECN tag is detected, it indicates that the link in the data center network is congested. The receiving end needs to calculate the total number of data packets received in one round-trip time as the network load. The network load in the data center network includes the bottleneck link load and the receiving end link load. Specifically, the bottleneck link load is the total number of data packets flowing through the bottleneck link in one round-trip time, and the receiving end link load is the total number of data packets received by the receiving end port in one round-trip time.

[0073] In some embodiments of the present invention, for different data center network architectures, the bottleneck link can be a link between switches or a link between an edge switch and a receiving end. For common topologies in data centers, such as... Figure 6 As shown, the data center topology convergence ratio is calculated as the ratio of uplink bandwidth between different layers, for example, the total bandwidth from the edge switch to the aggregation switch divided by the total bandwidth from the aggregation switch to the core switch. Typically, the uplink and downlink bandwidths within the same layer are equal. For asymmetric topologies, a convergence ratio greater than 1 indicates that the total link bandwidth between the core and aggregation switches is less than the total bandwidth between the aggregation switch and the edge switch. This further suggests that congestion will occur on the link between the core and aggregation switches, i.e., within the network topology itself. Therefore, the bottleneck link load is the total number of data packets received at the receiving end of the flow passing through the bottleneck link within a round-trip time. Similarly, for symmetric topologies, where the convergence ratio equals 1, network congestion can only occur at the last hop, i.e., the link between the edge switch and the receiving end. Therefore, the bottleneck link load is the total number of data packets received at the receiving end of the flow passing through this bottleneck link within a round-trip time.

[0074] Step S120: Add the network load information and the congestion flag information of the data packets to the ACK message fed back to the sender, so that the sender can adjust the size of the sending window to the total number of data packets received by the receiver based on the congestion flag and network load information in the received ACK message, so as to alleviate congestion.

[0075] In this step, based on the ECN tag detected in step S110 and the statistical network load, the receiving end adds the statistical bottleneck link load information, the receiving end link load information, and the ECN tag information carried in the data packet to the ACK message fed back to the sending end.

[0076] In some embodiments of the present invention, if each returned ACK packet carries network load information statistically analyzed by the receiver, congestion can be responded to more quickly, and the sending window can be converged to a fair window. A fair window is a sending window that fairly allocates bandwidth to all flows through the same link. Since the time of ACK packet feedback and the time of load statistics differ within the data center, the total number of data packets directly fed back in statistical analysis may differ from the actual load. Therefore, the present invention chooses to convert the receiving rate into the total number of received data packets by statistically analyzing the receiving rate and using the product of the rate and time, satisfying the following:

[0077] B = V * T;

[0078] Where B is the total number of data packets received in one round-trip time, V is the receiving rate, and T is one round-trip time; the bottleneck link load and the receiver link load can both be calculated using this formula. For the bottleneck link load, its receiving rate is the rate of the receiver's received stream; for the receiver link load, its rate is the total receiving rate of the receiver port.

[0079] Based on the above method of converting the receiving rate into the total number of received data packets by statistically analyzing the receiving rate and using the product of the rate and time, congestion can be responded to more quickly, the convergence speed can be increased, the convergence time can be reduced, and the problem of slow response speed and long convergence time of the reactive congestion control protocol can be avoided.

[0080] In some embodiments of the present invention, when the receiving end generates an ACK packet to be sent back to the sending end, it can add the network load information statistically obtained by the receiving end to the ACK packet header and payload through the kernel protocol stack. Furthermore, the receiving end adds the flag bit of the detected ECN tag to the ACK packet. The receiving end then sends the ACK packet containing the added network load information and congestion information to the sending end, so that the sending end can adjust the size of its sending window based on the received network load information to match the total number of data packets received by the receiving end, thereby alleviating network congestion.

[0081] As described above, the data center congestion control method based on network load provided in this application determines whether data center network congestion has occurred by detecting whether the received data packets carry congestion markers at the receiving end. Based on the detected congestion markers, the total number of data packets received by the receiving end is counted, and the total number of data packets is used as the network load of the data center network. The network load information and congestion marker information can be added to the ACK packet and the ACK packet can be sent to the sending end. This allows the sending end to adjust the size of the sending window to the corresponding total number of data packets received by the receiving end based on the congestion markers and network load information in the received ACK packet, thereby reducing the switch port queue length more quickly and effectively to alleviate congestion in the data center network.

[0082] Furthermore, the data center congestion control method based on network load, executed by the sending end, provided in the embodiments of this application, such as... Figure 7 The diagram illustrates a data center congestion control method based on network load, executed by the sending end, according to an embodiment of the present invention. The data center congestion control method based on network load further includes the following:

[0083] Step S130: Send data packets from the data center network to the switch through the sending window, receive ACK messages from the receiving end, and determine whether the received ACK messages carry congestion flags.

[0084] In one embodiment of the present invention, the sending end in the data center network sends data packets to the switch through a sending window. At this time, the size of the sending window is the number of data packets that the sending end has sent but has not received an ACK message for.

[0085] In one embodiment of the present invention, the sending end receives an ACK packet from the receiving end and checks whether the received ACK packet carries an ECN tag. If the received ACK packet does not carry an ECN tag, then there is no network congestion in the data center network, and the data flow has not passed through the congested link. The sending end will use a multiplicative increase in the sending window to reduce the window convergence time in order to utilize the idle bandwidth. The multiplicative increase in the sending window satisfies the following:

[0086]

[0087] Among them, W i The size of the sending window is γ, which represents the calculation parameter. This represents the receiver port load, Q. threshold This represents the threshold value, W. AI This represents the preset additive growth coefficient.

[0088] For the calculation parameter γ, the following is satisfied:

[0089] γ=γ*(1-g)+γ max *g;

[0090] Where g represents the preset moving average parameter, γ max This represents the preset parameter, which is usually set to 1.

[0091] For the load of the receiving port satisfy:

[0092]

[0093] in, This represents the load on the receiving end link, while lineRate represents the bandwidth on the receiving end link.

[0094] Based on the multiplicative growth method described above, on the one hand, the convergence time of the sending window is greatly shortened, reducing bandwidth waste; on the other hand, by using dynamically adjusted growth parameters, it can adapt to different network topology environments, avoiding the problem that existing active congestion control protocols cannot solve the problem of congestion with a convergence ratio greater than 1 in the topology.

[0095] Step S140: If it is determined that the received ACK message carries a congestion flag, the size of the sending window is adjusted to the size of the congested link load according to the congestion flag information and load network information in the returned ACK message, so as to alleviate congestion.

[0096] In one embodiment of the present invention, if the received ACK message carries an ECN flag, it indicates that the data flow has passed through a congested link. Based on the network load information in the received ACK message, the sending end adjusts the size of the sending window to the load size of the congested link, that is, the total number of data packets received by the receiving end in one round-trip time.

[0097] This can be understood as follows: within a round-trip time, the total number of data packets received by the receiver equals the total number of data packets allowed to flow through the bottleneck link. Since data packets exceeding the bottleneck link's bandwidth will accumulate in the queue and not be sent, the sender sets its sending window size to the corresponding total number of data packets received by the receiver, i.e., the number of data packets allowed to be sent by this flow on the bottleneck link. This eliminates the queue accumulation in the link. Therefore, its total sending window size can also be the product of the bottleneck link's total bandwidth and delay, satisfying:

[0098] BDP = Bandwidth * RTT;

[0099] Where BDP is the total bandwidth-delay product of the bottleneck link, Bandwidth is the bandwidth of the bottleneck link, and RTT is the round-trip time.

[0100] In one embodiment of the present invention, the sending end adjusts the size of the sending window based on the network load information in the received ACK packet, and the adjustment method also satisfies:

[0101]

[0102] Based on the bottleneck link load and receiver link load statistics in the ACK message, and combined with the multiplicative growth parameter, the size of the sending window is adjusted. When the sending window converges to the fair window, that is, when the flow sent by the sending window can fairly allocate the bandwidth of the link, it indicates that the congestion in the data center network has been alleviated.

[0103] As can be seen from the above description, the data center congestion control method based on network load provided in this application can significantly shorten the convergence time of the flow and reduce bandwidth waste by multiplicatively increasing the window. On the other hand, by using dynamically adjusted growth parameters, different additive growth strategies can be adopted when the congestion scale is different. This not only allows for faster detection of congestion in the additive growth stage in asymmetric topology cases, preventing the congestion control algorithm from entering the subsequent multiplicative growth stage and avoiding excessive rate increases, but also adapts to different network topology environments, avoiding the problem that existing proactive congestion control protocols cannot solve the problem of congestion with a convergence ratio greater than 1 in the topology.

[0104] In summary, the network load-based congestion control method for data centers proposed in this application can determine whether congestion has occurred in the data center network by detecting whether the received data packets carry congestion markers. Based on the detected congestion markers, the total number of data packets received by the receiver is counted, and the total number of data packets is used as the network load of the data center network. The method can add network load information and congestion marker information to the ACK packet and send the ACK packet to the sender. The method can receive the ACK packet from the receiver at the sender and adjust the size of the sending window to the total number of data packets received by the receiver based on the load information and congestion marker information in the ACK packet combined with a multiplicative growth parameter. This can more quickly and effectively reduce the queue length of switch ports and alleviate congestion in the data center network.

[0105] Corresponding to the above method, the present invention also provides a data center congestion control system based on network load. The system includes a computer device, which includes a processor and a memory. The memory stores computer instructions, and the processor is used to execute the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the steps of the method described above.

[0106] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned edge computing server deployment method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0107] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0108] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0109] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0110] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A data center congestion control method based on network load, characterized in that, include: Receive data packets from the switch and detect whether the data packets carry a congestion flag; If the data packet is marked with a congestion flag, the total number of data packets received by the receiving end within a preset time period is taken as the network load. The network load information and the congestion marking information of the data packets are added to the ACK message fed back to the sender, so that the sender can adjust the size of the sending window according to the congestion marking and network load information in the received ACK message to the total number of data packets received by the receiver, so as to alleviate congestion. The network load includes bottleneck link load and receiver link load. The receiving end link load is the total number of data packets received by the receiving end port within a preset time. The bottleneck link load is the total number of data packets received at the receiving end of the flow passing through the bottleneck link within a preset time. Wherein, the bottleneck link is a link between switches or a link between an edge switch and a receiving end; Both the bottleneck link load and the receiver link load are obtained by statistically analyzing the receiving rate and using the product of the rate and time. The method for adjusting the size of the sending window satisfies the following: ； in, For the size of the sending window, This represents the calculation parameters. This indicates the load on the receiving port. This represents the threshold value. This represents the preset additive growth coefficient; For calculation parameters satisfy: ； in, This represents the preset moving average parameters. This represents the preset parameters; For the load of the receiving port satisfy: ； in, This represents the load on the receiving end link. This represents the bandwidth of the receiving link.

2. The data center congestion control method according to claim 1, characterized in that, When the bottleneck link is a link between switches, the bottleneck link load is the total number of data packets received at the receiving end of the flow passing through the bottleneck link within a preset time. When the bottleneck link is the link between the edge switch and the receiver, the bottleneck link load is the total number of data packets of the flow received at the receiver within a preset time. The preset time is the round-trip time of a data packet.

3. The data center congestion control method according to claim 2, characterized in that, The bottleneck link load rate is the rate at which the receiver receives the stream; the receiver link load rate is the total rate at which the receiver port receives data packets.

4. The data center congestion control method according to claim 1, characterized in that, The step of adding the network load information and the congestion marking information of the data packets to the ACK message sent back to the sender includes: Based on the statistical network load, the network load information is added to the ACK message sent back to the sender via the kernel protocol stack; Based on the congestion marking of data packets, the flag bits of the detected congestion marking are added to the ACK message sent back to the sender.

5. A data center congestion control method based on network load, characterized in that, include: The system sends data packets from the data center network to the switch via a sending window, receives ACK packets from the receiving end, and determines whether the ACK packets carry a congestion flag. If the received ACK message contains a congestion flag, the size of the sending window is adjusted to match the load of the congested link based on the congestion flag information and network load information in the returned ACK message, thereby alleviating congestion. The congestion link load size is the total number of data packets received by the corresponding receiving end; The congested link load includes the bottleneck link load and the receiver link load; The receiving end link load is the total number of data packets received by the receiving end port within a preset time. The bottleneck link load is the total number of data packets received at the receiving end of the flow passing through the bottleneck link within a preset time. Wherein, the bottleneck link is a link between switches or a link between an edge switch and a receiving end; Both the bottleneck link load and the receiver link load are obtained by statistically analyzing the receiving rate and using the product of the rate and time. The method for adjusting the size of the sending window satisfies the following: ； in, For the size of the sending window, This represents the calculation parameters. This indicates the load on the receiving port. This represents the threshold value. This represents the preset additive growth coefficient; For calculation parameters satisfy: ； in, This represents the preset moving average parameters. This represents the preset parameters; For the load of the receiving port satisfy: ； in, This represents the load on the receiving end link. This represents the bandwidth of the receiving link.

6. The data center congestion control method according to claim 5, characterized in that, The method further includes: After the data packet sent by the sending end arrives at the switch, the switch determines whether the queue length of the data packet exceeds the threshold. If the queue length of the data packet exceeds a threshold, the switch marks the data packet as congested and sends the congestion-marked data packet to the receiving end.

7. The data center congestion control method according to claim 5, characterized in that, The method further includes: When the ACK message received by the sending end does not carry congestion information, the sending end will increase the window to use the idle bandwidth; The size of the sending window is the number of data packets sent by the sender but for which no ACK message has been received.

8. A congestion control system for data centers based on network load, comprising a processor and a memory, characterized in that, The memory stores computer instructions, and the processor executes the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the data center congestion control method as described in any one of claims 1 to 4, or implements the data center congestion control method as described in claims 5 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the data center congestion control method as described in any one of claims 1 to 4, or implements the data center congestion control method as described in claims 5 to 7.

Images