Network congestion control method and apparatus

Abstract

Provided in the embodiments of the present disclosure are a network congestion control method and apparatus. The method comprises: a receiving end acquiring congestion information of a data stream; the receiving end calculating a target sending rate of the data stream on the basis of the congestion information of the data stream; and the receiving end notifying a sending end of the target sending rate of the data stream, such that the sending end sends the data stream according to the target sending rate.

Description

Network congestion control method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This disclosure is based on and claims the priority of Chinese patent application No. 202311059412.8 filed on August 21, 2023, and all the disclosed contents are incorporated into this disclosure by reference. Technical Field

[0003] The present disclosure relates to the field of communications, and in particular to a method and apparatus for controlling network congestion. Background Art

[0004] Currently, the main methods for congestion and flow control include Data Center Quantized Congestion Notification (DCQCN), Data Center Quality of Service Control Network Plus (DCQCN+), and Perception Aware Congestion Control for Real-time Communication (PACC).

[0005] The congestion flow control algorithms of DCQCN and DCQCN+ primarily operate on the sending end. The receiving end receives ECN-marked packets from the switch, learns about switch congestion, and feeds this information back to the sending end in the form of a Congestion-Non-Positive Packet (CNP) packet after a period. The sending end then performs network congestion control calculations based on this CNP packet. However, the CNP packet does not reflect the number of ECN-marked packets received within a period, making it inaccurately reflecting the degree of congestion. Furthermore, since the information resides on the receiving end and the algorithm module resides on the sending end, the receiving end feeds congestion information back to the sending end in the form of CNP packets. The definition of this information, i.e., the parameters in the algorithm, must be consistent between the two ends, resulting in poor compatibility.

[0006] PACC implements a congestion flow control algorithm on switches. This provides accurate congestion information by measuring queue depth and the number of flows, significantly improving congestion flow control performance. However, the switches in this solution are designed for a specific transport protocol and congestion flow control algorithm. Therefore, the switches themselves cannot be standardized or universally applicable, and cannot even support data flows from multiple protocols passing through them simultaneously. Furthermore, switches are traffic aggregation points. As network bandwidth continues to increase, requiring switches to identify flows, calculate flow control values ​​for each flow, and generate flow control messages at line speed is impractical.

[0007] Summary of the Invention

[0008] The embodiments of the present disclosure provide a method and apparatus for controlling network congestion, so as to at least solve the problems in related arts such as the inability to accurately reflect the degree of congestion, poor compatibility, and low feasibility of congestion and flow control methods.

[0009] According to an embodiment of the present disclosure, a method for controlling network congestion is provided, including:

[0010] The receiving end obtains congestion information of the data stream;

[0011] The receiving end calculates the target sending rate of the data flow based on the congestion information of the data flow;

[0012] The receiving end notifies the sending end of a target sending rate of the data stream, wherein the sending end sends the data stream according to the target sending rate.

[0013] According to another embodiment of the present disclosure, a network congestion control device is provided, which is applied to a receiving end and includes:

[0014] A first acquisition module is configured to acquire congestion information of a data flow;

[0015] A first calculation module is configured to calculate a target sending rate of the data flow according to congestion information of the data flow;

[0016] The sending module is configured to notify a sending end of a target sending rate of a data stream, wherein the sending end sends the data stream according to the target sending rate.

[0017] According to another embodiment of the present disclosure, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when running.

[0018] According to another embodiment of the present disclosure, an electronic device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG1 is a schematic diagram of a control flow of existing network congestion;

[0020] FIG2 is a hardware structure block diagram of a mobile terminal according to a method for controlling network congestion according to an embodiment of the present disclosure;

[0021] FIG3 is a system architecture diagram of network congestion control according to an embodiment of the present disclosure;

[0022] FIG4 is a flow chart of a method for controlling network congestion according to an embodiment of the present disclosure;

[0023] FIG5 is a schematic diagram of a control flow of network congestion according to an embodiment of the present disclosure;

[0024] FIG6 is a schematic diagram of a weighting function for a large data stream and a small data stream according to an embodiment of the present disclosure;

[0025] FIG7 is a structural block diagram of a network congestion control device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0026] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings and in conjunction with embodiments.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0028] The classic seven-layer Open System Interconnect (OSI) protocol architecture, jointly developed by the International Organization for Standardization (ISO) and the International Telegraph and Telephone Consultative Committee (CCITT), provides a functional framework for open, interconnected information systems. From the lowest layer to the highest, it comprises: the physical layer, data link layer, network layer, transport layer, session layer, presentation layer, and application layer. The transport layer establishes an end-to-end link between hosts and provides end-to-end reliable and transparent data transmission services for upper-layer protocols, including handling issues such as error control, congestion, and flow control.

[0029] If the demand for a resource in the network exceeds the available portion of that resource over a period of time, network performance will deteriorate. That is, when the demand for a resource exceeds the available resource, network congestion occurs.

[0030] Congestion control is a dynamic process, usually compared using network load (the number of packets input to the network per unit time) and throughput (the number of packets output from the network per unit time). When network load exceeds throughput, the network becomes congested, and in severe cases, deadlock may occur.

[0031] Many congestion flow control algorithms are optimized and customized based on the data traffic characteristics of specific business scenarios. Data center distributed computing has become a key use case, encompassing AI, VR, and other applications.

[0032] However, distributed computing paradigms such as the parameter server model and the global reduction Allreduce model, as well as underlying algorithms such as the binomial tree and ring algorithms, all lead to traffic asymmetry:

[0033] 1) The receiving end and the sending end use a one-to-many communication mode called incast, and the number of data streams at the receiving end and the sending end is asymmetric.

[0034] 2) Data traffic is unevenly distributed in time, with intermittent bursts, and a large amount of data is transmitted at a time but the duration is short.

[0035] 3) The forward and reverse data traffic of a data flow is asymmetric. Data is transmitted in one direction at the same time, and the reverse bandwidth resources are idle.

[0036] Therefore, to address the asymmetric data flow between the data receiver and sender caused by incast in a one-to-many communication mode, a congestion flow control mechanism must first be able to assess the incast scale. To address intermittent bursts of data traffic, a congestion flow control algorithm must avoid severe congestion in the initial stages of data flow transmission and respond and converge quickly when congestion occurs, thereby improving bandwidth utilization and reducing long-tail latency. To enable large-scale networking, the congestion flow control algorithm must be compatible and feasible.

[0037] However, the existing DCQCN and DCQCN+ congestion flow control algorithms (Figure 1 is a schematic diagram of the control flow for existing network congestion). Referring to Figure 1, the receiving end receives packets sent by the sending end that are marked with an Explicit Congestion Notification (ECN) and generates a Congestion Notification Packet (CNP) message. The sending end receives the CNP message, calculates the data flow's sending rate based on the CNP message, and sends data at that calculated sending rate. The receiving end perceives the information and remotely transmits it to the sending end, which then makes the decision. This results in inaccurate conversion of congestion information. Furthermore, the sending end cannot assess the scale of incast and requires consistent parameters in the algorithms on both ends, resulting in poor compatibility. Furthermore, the receiving end does not count the number of ECN-marked packets; instead, it checks every preset period to see if any are marked. If so, a CNP message is generated and sent to the data sending end. This CNP approach cannot accurately reflect the level of congestion.

[0038] The switch in the PACC congestion flow control algorithm is designed for a specific congestion flow control protocol. The switch is not compatible and universal, making it difficult to implement.

[0039] The technical concept of this embodiment is that the receiving end obtains congestion information, calculates the target sending rate of the data flow based on the congestion information, and notifies the sending end of the target sending rate. The sending end then sends the data flow at the target sending rate. By implementing a flow control algorithm on the receiving end, more accurate congestion information can be obtained, allowing for precise adjustment of the data flow sending rate. This approach also eliminates the need for custom switches, ensuring high feasibility and compatibility.

[0040] The method embodiments provided in the embodiments of the present disclosure can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking operation on a computer terminal as an example, FIG2 is a hardware structure block diagram of a computer terminal of a network congestion control method according to an embodiment of the present disclosure. As shown in FIG2 , the computer terminal may include one or more (only one is shown in FIG2 ) processors 202 (the processor 202 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 204 for storing data, wherein the above-mentioned computer terminal may also include a transmission device 206 and an input and output device 208 for communication functions. It will be understood by those skilled in the art that the structure shown in FIG2 is only for illustration and does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal may also include more or fewer components than those shown in FIG2 , or have a configuration different from that shown in FIG2 .

[0041] The memory 204 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the network congestion control method in the embodiment of the present disclosure. The processor 202 executes various functional applications and data processing by running the computer program stored in the memory 204, that is, implementing the above-mentioned method. The memory 204 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 204 may further include a memory remotely located relative to the processor 202, and these remote memories may be connected to the computer terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0042] Transmission device 206 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a communications provider of a computer terminal. In one embodiment, transmission device 206 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 206 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0043] Figure 3 is a system architecture diagram for controlling network congestion according to an embodiment of the present disclosure. The embodiment of the present disclosure can operate on the network architecture shown in Figure 3. As shown in Figure 3, the network architecture includes: a sending end, a switch, and a receiving end. The sending end is used to send data according to the sending rate of the data stream and can send the data stream to the switch; the switch is used to ECN mark the messages in the data stream according to a certain probability and send them to the receiving end; the receiving end is used to obtain congestion information based on the ECN-marked message information, and perform calculations to obtain the sending rate of the data stream and then send it to the sending end.

[0044] In this embodiment, a method for controlling network congestion running on the above system architecture is provided. FIG4 is a flow chart of the method for controlling network congestion according to an embodiment of the present disclosure. As shown in FIG4 , the flow chart includes the following steps:

[0045] Step S401: The receiving end obtains congestion information of the data flow.

[0046] In the embodiment of the present disclosure, congestion information of a data stream is obtained by a receiving end, so as to calculate a sending rate of the data stream based on the congestion information.

[0047] In an exemplary embodiment, the congestion information includes at least one of the following information:

[0048] The number of packets within a preset period, the number of packets marked by explicit congestion notification (ECN) within the preset period, and the current sending rate of the data flow.

[0049] As an example, the receiving end may count the number of packets in the data stream and the number of packets marked by ECN every preset period to obtain the number of packets in the preset period and the number of packets marked by ECN in the preset period.

[0050] Exemplarily, the receiving end may obtain information such as the number of packets in a preset period of the data stream, the number of packets marked by ECN in the preset period, and the current sending rate of the data stream.

[0051] Explicit Congestion Notification (ENC) is an extension of the TCP / IP protocol and is defined in RFC 3168 (2001). When a switch supporting ECN experiences congestion, it can set two bits (called ECT(0) and ECT(1)) in the IP packet header to '11' before forwarding it, explicitly notifying the receiving end of the congestion.

[0052] FIG5 is a schematic diagram of the control flow for network congestion according to an embodiment of the present disclosure. Referring to FIG4 , the present disclosure embodiment detects and calculates congestion information at the receiving end, eliminating the need for remote information transmission. This can speed up the frequency of congestion information perception. Furthermore, the receiving end and the transmitting end do not need to negotiate consistent parameters, making them more independent. In an exemplary embodiment, the current sending rate of the data stream is the initial sending rate. Before the receiving end obtains the congestion information for the data stream, the following steps are further included: the receiving end obtains the number of data streams and the physical bandwidth of the link; and the receiving end calculates the initial sending rate for each data stream based on the number of data streams and the physical bandwidth of the link.

[0053] In an embodiment of the present disclosure, if the current sending rate of the data stream is the initial sending rate, the initial sending rate of each data stream can be pre-set before the receiving end obtains the congestion information of the data stream, so that the sending end can be planned when initially sending the data stream and can quickly reach a steady state, thereby avoiding congestion in the initial stage of data transmission caused by unplanned full-speed sending by the sending end.

[0054] As an example, each time a receiving end establishes a connection with each sending end, each sending end can transmit data via a data stream. The receiving end can count the number of connections established with each sending end, determine the number of data streams based on the number of established connections, and simultaneously obtain the physical link bandwidth of the data streams. Based on the number of data streams and the physical link bandwidth, the initial transmission rate of each data stream can be calculated. The physical link bandwidth in the disclosed embodiment is the physical bandwidth of the transmission link established between the receiving end and the switch.

[0055] For example, the receiving end can count the number of data flows m in the current connection and obtain the corresponding link physical bandwidth L. The ratio of the link physical bandwidth L to the number of data flows m with the same port number is used as the initial sending rate of each data flow, that is, R0 = L / m.

[0056] As an example, when the sender and the receiver establish a new data stream and start transmission, the receiver can update the current number of connections, or the receiver can count the current number of connections between the sender and the receiver every preset period. The embodiments of the present disclosure do not limit this.

[0057] Step S402: The receiving end calculates a target sending rate of the data flow according to the congestion information of the data flow.

[0058] As an example, the receiving end may calculate the target sending rate of the data flow according to the congestion information of the data flow.

[0059] In an exemplary embodiment, the congestion information includes the number of packets within a preset period, the number of packets marked by an explicit congestion notification (ECN) within the preset period, and the current sending rate of the data flow. The receiving end calculates the target sending rate of the data flow based on the congestion information of the data flow, including: determining, by the receiving end, a probability that the packet is marked by ECN based on the number of packets within the preset period and the number of packets marked by the explicit congestion notification (ECN); obtaining, by the receiving end, a mapping relationship between the probability and a relative queue length of a port queue; and determining, by the receiving end, the target sending rate of the data flow based on the probability, the mapping relationship between the probability and the relative queue length of the port queue, and the current sending rate of the data flow.

[0060] Referring to Figure 5 , since congestion information perception and calculation are both performed at the receiving end, the receiving end can count the number of packets within a preset period and the number of packets marked by ECN, and then calculate the probability P of a packet being marked by ECN. This P value can more accurately reflect the degree of network congestion and more accurately calculate the required sending rate of the data flow.

[0061] For example, the receiving end can count the total number of packets N in the data flow within a preset period and the number of packets marked by ECN E, and calculate the probability of the packet being marked by ECN, that is, P = E / N. From this, the ECN marking probability P can be restored to know the congestion level of the switch point, which is used to calculate the target sending rate of the data flow.

[0062] As an example, there is a mapping relationship between probability P and the relative length Q of the port queue. The receiving end calculates the target data flow rate R based on probability P, the mapping relationship between P and Q, and the current data flow rate Rc. As an example, in addition to calculating the probability P of a packet being ECN-marked, the congestion level of a switch port can also be calculated by statistically analyzing the distribution of ECN packets at the receiving end. For example, if the number of ECN packets decreases over multiple consecutive periods, it can be determined that the switch port congestion level is decreasing.

[0063] In an exemplary embodiment, the receiving end calculates the target sending rate of the data stream based on the probability, the mapping relationship between the probability and the relative length of the port queue, and the current sending rate of the data stream, including: the receiving end determines the relative length of the port queue based on the probability, the mapping relationship between the probability and the relative length of the port queue; the receiving end calculates the target sending rate of the data stream based on the relative length of the port queue and the current sending rate of the data stream.

[0064] As an example, the receiving end can calculate the relative queue length Q of the port queue based on the probability P of the packet being ECN marked, the mapping relationship between the probability P of the packet being ECN marked, and the relative queue length Q of the port queue. For example, if the mapping relationship P=Q among P, probability P, and the relative queue length Q of the port queue is known, Q can be calculated.

[0065] As an example, after calculating the relative length Q of the port queue, Q and RC can be input into the calculation formula for calculating the target sending rate R, for example, R = Rc (1-0.2Q)

[0066] The target sending rate R of the data flow is thereby calculated. In an exemplary embodiment, the receiving end determines the relative length of the port queue based on the probability and the mapping relationship between the probability and the relative length of the port queue, including: the receiving end obtains the weight of the data flow; and the receiving end determines the relative length of the port queue based on the weight of the data flow, the probability, and the mapping relationship between the probability and the relative length of the port queue.

[0067] As an example, the weight of a data flow may be the weight corresponding to the ratio of the current sending rate of the data flow to the physical bandwidth of the link.

[0068] As an example, the receiving end can obtain the weight of the data flow and determine the relative length of the port queue based on the mapping relationship between the weight of the data flow, the probability of the message being ECN marked, the probability of the message being ECN marked and the relative length of the port queue.

[0069] For example, the relative length Q of the port queue, the probability P of the message being marked by ECN, and the weight of the data flow The relationship expression can be:

[0070] The relative length Q of the port queue can be calculated using the above formula.

[0071] In an exemplary embodiment, before configuring different weights for the large data stream and the small data stream respectively, it also includes: the receiving end divides the data stream into the large data stream and the small data stream according to the ratio of the current sending rate of the data stream to the physical bandwidth of the link; wherein, the data stream whose current sending rate to the physical bandwidth of the link is greater than or equal to the preset ratio is the large data stream; and the data stream whose current sending rate to the physical bandwidth of the link is less than the preset ratio is the small data stream.

[0072] As an example, the receiving end may divide the data flow into a large data flow and a small data flow according to a ratio Rc / L of the current transmission rate Rc of the data flow to the physical bandwidth L of the link.

[0073] For example, Rc / L≥0.1 can be determined as a large data flow, and Rc / L<0.1 can be determined as a small data flow.

[0074] In an exemplary embodiment, the data stream includes a large data stream and a small data stream. Before the receiving end obtains the weight of the current data stream, it also includes: the receiving end obtains the ratio of the current sending rate of the data stream to the physical bandwidth of the link and the correspondence between the ratio and the weight; the receiving end configures different weights for the large data stream and the small data stream respectively according to the ratio and the correspondence.

[0075] For example, a receiving end can categorize data flows into large and small flows. However, the switch does not distinguish between large and small flows when marking packets with ECN; instead, it randomly applies ECN marking. The more packets a flow contains, the more likely it is to be marked with ECN. However, during short periods of speed regulation and congestion, there is a certain degree of randomness. For small flows, marking them once increases their probability of being marked with ECN, due to their low transmission rate, leading to a significant speed reduction and potential accidental damage.

[0076] Small data flows are generally signaling, control, and other messages, and have low expected latency. Small data flows are not the main cause of congestion, and slowing down small data flows has limited contribution to relieving congestion. Therefore, different weights can be assigned to large and small data flows.

[0077] As an example, the receiving end can obtain the ratio of the current sending rate of the data stream to the physical bandwidth of the link and the correspondence between the ratio and the weight, and configure different weights for large data streams and small data streams according to the ratio of the current sending rate of the data stream to the physical bandwidth of the link and the correspondence between the ratio and the weight.

[0078] As an example, FIG6 is a schematic diagram of a weighted function for a large data stream and a small data stream according to an embodiment of the present disclosure. Referring to FIG6 , the corresponding relationship between the ratio of the current transmission rate to the link physical bandwidth and the weight can be:

[0079] Where x is the ratio of the data flow's current transmission rate to the link's physical bandwidth, Rc / L, and f(x) is the weight. A data flow with Rc / L ≥ 0.1 can be identified as a large data flow, with a weight of 100%. A data flow with Rc / L < 0.1 can be identified as a small data flow, with the corresponding weight varying linearly with Rc / L. Data flows with Rc / L ≈ 0 have a weight of 10%.

[0080] Step S403: The receiving end notifies the sending end of the target sending rate of the data stream, so that the sending end sends the data stream according to the target sending rate.

[0081] After determining the relative length Q of the port queue, the target sending rate of the data flow can be calculated based on the relative length Q of the port queue, the sending rate Rc of the current data flow, and the mapping relationship between the relative length Q of the port queue and the sending rate R of the data flow.

[0082] For example, the mapping relationship between the relative length Q of the port queue and the sending rate R of the data flow can be: R = Rc (1-0.2Q)

[0083] The relative length Q of the port queue and the sending rate Rc of the current data flow can be input into the above formula to calculate the target sending rate of the data flow.

[0084] As an example, the receiving end may notify the sending end of the target sending rate of the data stream. After receiving the notification message, the sending end sends the data stream according to the target sending rate in the notification message.

[0085] In an exemplary embodiment, the receiving end notifies the sending end of the target sending rate of the data stream so that the sending end sends the data stream according to the target sending rate, including: the receiving end attaching the target sending rate of the data stream to an acknowledgment ACK message, and notifying the sending end through the ACK message so that the sending end sends the data stream according to the target sending rate; or, the receiving end converts the target sending rate of the data stream into the number of single-sent messages, and attaches the number of single-sent messages to a credit token, and notifies the sending end through the credit token so that the sending end sends messages according to the number of single-sent messages.

[0086] As an example, the receiving end may notify the sending end of the target sending rate of the data stream in the following two ways:

[0087] Method 1: The receiving end appends the target sending rate of the data stream to the ACK message and notifies the sending end through the ACK message so that the sending end can send the data stream at the target sending rate.

[0088] Method 2: The receiving end can convert the target sending rate of the data stream into the number of messages sent in a single batch, and append the number of messages sent in a single batch to the credit token. The credit token is used to notify the sending end so that the sending end can send messages according to the number of messages sent in a single batch.

[0089] The disclosed embodiments obtain congestion information from the receiving end, calculate the target sending rate of the data stream based on the congestion information, and notify the sending end of the target sending rate. The sending end then sends the data stream at the target sending rate. Implementing a flow control algorithm at the receiving end eliminates the need to replace switches, not only controls network congestion but also offers excellent feasibility and compatibility. This addresses the issues of related congestion and flow control methods, such as their inability to accurately reflect congestion levels, poor compatibility, and low feasibility.

[0090] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present disclosure.

[0091] This embodiment also provides a network congestion control device for implementing the above-mentioned embodiments and exemplary implementations. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0092] FIG7 is a structural block diagram of a network congestion control device according to an embodiment of the present disclosure, which is applied to a receiving end. As shown in FIG2 , the device includes:

[0093] A first acquisition module 701 is configured to acquire congestion information of a data flow;

[0094] A first calculation module 702 is configured to calculate a target sending rate of the data flow according to the congestion information of the data flow;

[0095] The sending module 703 is configured to notify the sending end of the target sending rate of the data stream, wherein the sending end sends the data stream according to the target sending rate.

[0096] In an exemplary embodiment, the congestion information includes at least one of the following information:

[0097] The number of packets within a preset period, the number of packets marked by explicit congestion notification (ECN) within the preset period, and the current sending rate of the data flow.

[0098] In an exemplary embodiment, the congestion information includes the number of packets within a preset period, the number of packets marked by explicit congestion notifications (ECNs) within the preset period, and the current sending rate of the data flow. The first calculation module 702 includes:

[0099] A first determining submodule is configured to determine a probability that the message is marked by an explicit congestion notification (ECN) based on the number of messages in the preset period and the number of messages marked by ECN;

[0100] An acquisition submodule, configured to obtain a mapping relationship between the probability and the relative length of the port queue;

[0101] The second determining submodule is configured to determine a target sending rate of the data flow according to the probability, a mapping relationship between the probability and the relative length of the port queue, and a current sending rate of the data flow.

[0102] In an exemplary embodiment, the second determining submodule includes:

[0103] a determining unit configured to determine the relative length of the port queue according to the probability and a mapping relationship between the probability and the relative length of the port queue;

[0104] The calculation unit is configured to calculate the target sending rate of the data flow according to the relative length of the port queue and the current sending rate of the data flow. In an exemplary embodiment, the determination unit includes:

[0105] an acquisition subunit, configured to acquire a weight of the data stream;

[0106] The determination subunit is configured to determine the relative length of the port queue according to the weight of the data flow, the probability, and a mapping relationship between the probability and the relative length of the port queue.

[0107] In an exemplary embodiment, the data stream includes a large data stream and a small data stream, and the apparatus further includes:

[0108] a second obtaining subunit, configured to obtain a ratio of a current sending rate of the data flow to a physical bandwidth of the link and a corresponding relationship between the ratio and the weight before the receiving end obtains the weight of the current data flow;

[0109] The configuration subunit is configured to configure different weights for the large data flow and the small data flow respectively according to the ratio and the corresponding relationship.

[0110] In an exemplary embodiment, the apparatus further comprises:

[0111] The classification subunit is configured to divide the data stream into the large data stream and the small data stream according to the ratio of the current sending rate of the data stream to the physical bandwidth of the link before configuring different weights for the large data stream and the small data stream respectively; wherein, the data stream whose ratio of the current sending rate to the physical bandwidth of the link is greater than or equal to the preset ratio is the large data stream; and the data stream whose ratio of the current sending rate to the physical bandwidth of the link is less than the preset ratio is the small data stream.

[0112] In an exemplary embodiment, the current sending rate of the data stream is the initial sending rate, and the apparatus further includes:

[0113] A second acquisition module is configured to obtain the number of the data flows and the physical bandwidth of the link;

[0114] The second calculation module is configured to calculate an initial sending rate of each of the data flows according to the number of the data flows and the physical bandwidth of the link.

[0115] In an exemplary embodiment, the sending module 703 includes:

[0116] The sending submodule is configured to attach the target sending rate of the data stream to an acknowledgment ACK message, and notify the sending end through the ACK message so that the sending end sends the data stream according to the target sending rate; or convert the target sending rate of the data stream into the number of single-sending messages, and attach the number of single-sending messages to a credit token, and notify the sending end through the credit token so that the sending end sends messages according to the number of single-sending messages.

[0117] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0118] An embodiment of the present disclosure further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when run.

[0119] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0120] An embodiment of the present disclosure further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0121] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0122] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0123] Obviously, those skilled in the art should understand that the modules or steps of the present disclosure described above can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices, they can be implemented using program code executable by the computing device, and thus, they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be performed in a different order than herein, or they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module for implementation. Thus, the present disclosure is not limited to any particular combination of hardware and software.

[0124] The foregoing is merely an exemplary embodiment of the present disclosure and is not intended to limit the present disclosure. Those skilled in the art will readily appreciate that the present disclosure is susceptible to various modifications and variations. Any modifications, equivalent substitutions, improvements, and the like made within the principles of the present disclosure shall be included within the scope of protection of the present disclosure.

Claims

1. A method for controlling network congestion, comprising: The receiving end obtains the congestion information of the data stream; The receiving end calculates a target sending rate of the data flow according to the congestion information of the data flow; The receiving end sends the target sending rate of the data stream to the sending end, wherein the sending end sends the data stream according to the target sending rate.

2. The method according to claim 1, wherein: The congestion information includes at least one of the following information: The number of messages within a preset period, the number of messages marked by explicit congestion notification (ECN) within the preset period, and the current sending rate of the data flow.

3. The method according to claim 1, wherein: The congestion information includes the number of messages within a preset period, the number of messages marked by explicit congestion notifications (ECN) within the preset period, and the current sending rate of the data flow. The receiving end calculates the target sending rate of the data flow according to the congestion information of the data flow, including: The receiving end determines the probability that the message is marked by ECN according to the number of messages in the preset period and the number of messages marked by ECN; The receiving end obtains a mapping relationship between the probability and the relative length of the port queue; The receiving end determines the target sending rate of the data flow according to the probability, the mapping relationship between the probability and the relative length of the port queue, and the current sending rate of the data flow.

4. The method according to claim 3, wherein: The receiving end calculates a target sending rate of the data stream according to the probability, a mapping relationship between the probability and the relative length of the port queue, and a current sending rate of the data stream, including: The receiving end determines the relative length of the port queue according to the probability and the mapping relationship between the probability and the relative length of the port queue; The receiving end determines a target sending rate of the data flow according to the relative length of the port queue and the current sending rate of the data flow.

5. The method according to claim 4, wherein: The receiving end determines the relative length of the port queue according to the probability and the mapping relationship between the probability and the relative length of the port queue, including: The receiving end obtains the weight of the data stream; The receiving end determines the relative length of the port queue according to the weight of the data flow, the probability, and a mapping relationship between the probability and the relative length of the port queue.

6. The method according to claim 5, wherein: The data stream includes a large data stream and a small data stream, and before the receiving end obtains the weight of the current data stream, it also includes: The receiving end obtains a ratio of a current transmission rate of the data stream to a physical bandwidth of a link, and a corresponding relationship between the ratio and the weight; The receiving end configures different weights for the large data stream and the small data stream respectively according to the ratio and the corresponding relationship.

7. The method according to claim 6, wherein: Before respectively configuring different weights for the large data stream and the small data stream, the method further includes: The receiving end divides the data stream into the large data stream and the small data stream according to the ratio of the current sending rate of the data stream to the physical bandwidth of the link; The data flow whose ratio of the current transmission rate to the link physical bandwidth is greater than or equal to the preset ratio is the large data flow; The data flow whose ratio of the current sending rate to the link physical bandwidth is smaller than the preset ratio is the small data flow.

8. The method according to claim 1, wherein: The current sending rate of the data stream is the initial sending rate, and before the receiving end obtains the congestion information of the data stream, the method further includes: The receiving end obtains the number of the data streams and the physical bandwidth of the link; The receiving end calculates an initial sending rate of each of the data streams according to the number of the data streams and the physical bandwidth of the link.

9. The method according to claim 1, wherein: The receiving end notifies the sending end of the target sending rate of the data stream so that the sending end sends the data stream according to the target sending rate, including: The receiving end adds the target sending rate of the data stream to an ACK message, and notifies the sending end through the ACK message, so that the sending end sends the data stream according to the target sending rate; or, The receiving end converts the target sending rate of the data stream into the number of messages sent at a single time, and appends the number of messages sent at a single time to the credit token, and notifies the sending end through the credit token so that the sending end sends messages according to the number of messages sent at a single time.

10. A network congestion control device, applied to a receiving end, the device comprising: A first acquisition module, configured to acquire congestion information of a data stream; A first calculation module, configured to calculate a target sending rate of the data flow according to the congestion information of the data flow; The sending module is configured to notify the sending end of a target sending rate of the data stream, wherein the sending end sends the data stream according to the target sending rate.

11. The device according to claim 10, wherein: The congestion information includes at least one of the following information: The number of messages within a preset period, the number of messages marked by explicit congestion notification (ECN) within the preset period, and the current sending rate of the data flow.

12. The device according to claim 11, wherein The computing module comprises: A determination submodule, configured such that the receiving end determines the probability that a message is marked by ECN according to the number of messages and the number of messages marked by ECN; An acquisition submodule, configured to acquire a mapping relationship between the probability and a relative length of a port queue; The calculation submodule is configured to calculate the probability of the receiving end according to the mapping between the probability and the relative length of the port queue. The target sending rate of the data stream is calculated based on the radiation relationship and the current sending rate of the data stream.

13. A computer-readable storage medium having a computer program stored therein, wherein: When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 9 are implemented.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method described in any one of claims 1 to 9 when executing the computer program.

Images