A traffic congestion processing method and system for high-speed data center network

Abstract

The application provides a traffic congestion processing method and system for a high-speed data center network, and the method comprises the following steps: a receiving end switch receives a data packet from a long-distance link, and a forwarding queue corresponding to a destination is constructed based on the destination of the data packet; a congestion notification message fed back by the forwarding queue corresponding to a receiving end host connected with the receiving end switch is acquired, a congestion degree value is calculated based on the congestion notification message, and a flight byte threshold value is determined based on the congestion degree value; the number of flight bytes is calculated based on the bytes sent in each forwarding queue, and the number of flight bytes is compared with the flight byte threshold value to determine whether the traffic of the corresponding forwarding queue is congested; and if the traffic of any forwarding queue is congested, the congested traffic of the forwarding queue is controlled. The scheme can react in advance in the flight stage of bytes, realize congestion control in advance, and ensure the overall performance.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data communication, and in particular to a traffic congestion processing method and system for high-speed data center network. BACKGROUND

[0002] Remote Direct Memory Access (RDMA) technology, as a high-speed network technology, is increasingly favored by network-intensive applications such as machine learning and cloud storage. RDMA achieves ultra-low latency, high throughput, and almost no CPU resource consumption by bypassing the kernel and offloading the network stack to the network card, so data centers have adopted RDMA to improve network performance and meet the stringent performance requirements of application programs. For example, in Microsoft Azure, about 70% of the traffic has adopted RDMA technology. In recent years, with the popularity of geographically distributed applications, service providers increasingly distribute data storage and computing resources among multiple data centers. Many data-intensive applications, such as big data analysis, machine learning, graph computing, and high-performance computing, involve large data sets distributed across multiple data centers and require processing and storing massive data across multiple data centers. These data centers are directly connected through a cross-data center network formed by dedicated optical fibers and DCI exchange mechanisms, which provides operators with the ability to establish and manage cross-data center RDMA connections compared to wide area networks. In addition, using RDMA across data centers also relieves operators of the burden of managing two separate network interfaces simultaneously. Therefore, in order to fully utilize the advantages of RDMA, it is crucial to provide long-distance RDMA transmission for cross-data center applications.

[0003] The RTT of dedicated long-distance links between data centers is usually in the order of hundreds of microseconds to milliseconds, which is much larger than the RTT within a single data center. Therefore, long-distance traffic transmission has a relatively long control loop; however, host-driven algorithms have the problem of long control loop time on cross-data center links, which cannot detect congestion in time, resulting in a lag in end-to-end congestion control and seriously affecting overall performance. SUMMARY

[0004] In view of this, the embodiments of the present application provide a traffic congestion processing method for high-speed data center network to eliminate or improve one or more defects in the prior art.

[0005] One aspect of the present application provides a traffic congestion processing method for high-speed data center network, the steps of the method comprising:

[0006] The receiving end switch receives data packets from the long-distance link, and constructs a forwarding queue corresponding to the destination based on the destination of the data packets;

[0007] The congestion notification message fed back by the corresponding forwarding queue of the receiving end host connected with the receiving end switch is acquired, the congestion degree value is calculated based on the congestion notification message, and the flying byte threshold is determined based on the congestion degree value;

[0008] The flying byte number is calculated based on the bytes sent in each forwarding queue, and the flying byte number is compared with the flying byte threshold to determine whether the traffic of the corresponding forwarding queue is congested;

[0009] If the traffic of any forwarding queue is congested, the congested traffic of the forwarding queue is controlled.

[0010] With the above scheme, in the processing of a long-distance link, the receiving end switch first constructs the forwarding queue corresponding to each destination according to the destination of the data packet, and the flying byte number is calculated based on the bytes sent in each queue. In the scheme, the flying byte threshold can be updated in real time, and whether congestion occurs is determined based on the comparison between the current flying byte threshold and the flying byte number. Early reaction can be performed in the flying stage of the byte, and congestion control can be realized in advance to ensure overall performance.

[0011] In some embodiments of the present application, in the step of acquiring the congestion notification message fed back by the corresponding forwarding queue of the receiving end host connected with the receiving end switch, calculating the congestion degree value based on the congestion notification message, and determining the flying byte threshold based on the congestion degree value, the initial value of the congestion degree value is 0, and the congestion degree value of a forwarding queue is increased by 1 for each received congestion notification message.

[0012] In some embodiments of the present application, in the step of acquiring the congestion notification message fed back by the corresponding forwarding queue of the receiving end host connected with the receiving end switch, calculating the congestion degree value based on the congestion notification message, and determining the flying byte threshold based on the congestion degree value, if the receiving end switch receives the congestion notification message again within a preset time period after receiving the congestion notification message for a forwarding queue, the congestion degree value of the forwarding queue is increased by 1; and if the receiving end switch does not receive the congestion notification message within the preset time period after receiving the congestion notification message for a forwarding queue, the congestion degree value of the forwarding queue is reset to the initial value.

[0013] In some embodiments of the present application, in the step of acquiring the congestion notification message fed back by the corresponding forwarding queue of the receiving end host connected with the receiving end switch, calculating the congestion degree value based on the congestion notification message, and determining the flying byte threshold based on the congestion degree value:

[0014] Threshold=BDP*(1-degree / degreeT);

[0015] Wherein, Threshold represents the flight byte threshold, BDP represents the bandwidth delay product, degree represents the current congestion degree value, and degreeT represents the upper limit value of the congestion degree value.

[0016] In some embodiments of the present application, in the step of calculating the flight bytes based on the bytes sent in each forwarding queue, the flight bytes are calculated based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the ACK packets returned by the receiving end host.

[0017] In some embodiments of the present application, in the step of calculating the flight bytes based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the ACK packets returned by the receiving end host, the number of received bytes Byte_rcv is determined based on the ACK packets returned by the receiving end host, and the flight bytes are calculated based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the number of received bytes Byte_rcv.

[0018] In some embodiments of the present application, in the step of calculating the flight bytes based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the number of received bytes Byte_rcv, the flight bytes are calculated based on the following formula:

[0019] InflightByte=Byte_send-Byte_rcv;Wherein, InflightByte represents the number of flight bytes.

[0020] In some embodiments of the present application, in the step of comparing the number of flight bytes with the flight byte threshold to determine whether the traffic of the corresponding forwarding queue is congested, if the number of flight bytes is greater than the flight byte threshold, it is determined that the traffic of the corresponding forwarding queue is congested.

[0021] In some embodiments of the present application, in the step of controlling the congested traffic of the forwarding queue if the traffic of any forwarding queue is congested, if the traffic of any forwarding queue is congested, the output of the traffic of the forwarding queue is suspended, and when the number of flight bytes of the forwarding queue is not greater than the flight threshold, the data forwarding of the forwarding queue is resumed.

[0022] The second aspect of the present application also provides a traffic congestion processing system for high-speed data center network, which comprises a computer device, the computer device comprises a processor and a memory, the memory stores computer instructions, and the processor is used to execute the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the system implements the steps as implemented by the method described above.

[0023] A third aspect of the invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned traffic congestion handling method for high-speed data center networks.

[0024] 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 text, or may be learned by practice of the invention. The objects and other advantages of the invention will become apparent from the description and the accompanying drawings.

[0025] 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

[0026] The accompanying drawings, which are provided to further illustrate the invention and form part of this application, are not intended to limit the scope of the invention.

[0027] Figure 1 This is a schematic diagram of one embodiment of the traffic congestion handling method for high-speed data center networks according to the present invention;

[0028] Figure 2 This is a schematic diagram of the processing framework of this solution. Detailed Implementation

[0029] 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.

[0030] 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.

[0031] Introduction to existing technologies:

[0032] Existing technology 1:

[0033] With the upgrade of data center hardware and the rapid development of network technology, network bandwidth gradually presents an exponential growth trend. When the network bandwidth reaches a certain scale, the bottleneck of data transmission begins to shift from the network side to the server side. The traditional TCP / IP protocol needs to make frequent system calls in the data transmission process, and its performance is limited by the processing capacity of the CPU. This design leads to excessive processing delay under high throughput requirements, making it difficult to meet the demand for efficient communication in modern data centers. In contrast, the RDMA technology can provide up to 100 Gbps or even higher throughput on each connection and significantly reduce the dependence on CPU resources, especially in network stack processing and interrupt management. This makes RDMA an important technology to solve the communication needs of large-scale data centers. When the business needs to communicate across multiple data centers, it is particularly important to continue using RDMA technology to handle high throughput requirements on remote links. Especially on long-distance links across data centers, the advantage of RDMA is particularly prominent, as it can fully utilize existing hardware capabilities, reducing the additional overhead introduced by the traditional protocol stack while ensuring throughput.

[0034] However, the higher network latency across data center networks not only affects the real-time performance of data transmission, but also increases the recovery time after packet loss. This requires RDMA to combine with lossless flow control PFC (Priority Flow Control) to significantly reduce packet loss caused by network congestion, thereby ensuring efficient data transmission. PFC is a fine flow control mechanism that can meet the lossless requirements of Ethernet traffic transmission and provide lossless services through Ethernet. PFC allows the creation of 8 virtual channels on an Ethernet link, and each virtual channel is assigned a priority level. Any virtual channel can be individually paused and restarted without affecting the forwarding of other channel traffic. Through this mechanism, multiple types of traffic can coexist on the same interface, and multiple types of traffic can share the link. When congestion occurs at the local end, the device will determine the processing method for the packet based on the priority of the received packet: if the priority of the received packet has enabled the PFC function, the packet is received, and a PFC PAUSE frame is sent to the opposite end to notify the opposite end device to temporarily stop sending packets of this type. After receiving the PFC PAUSE frame, the opposite end device will temporarily stop sending packets of this type to the local end. When congestion still exists, this process will be repeated until the congestion is resolved. If the priority of the received packet does not enable the PFC function, the packet is discarded directly.

[0035] Disadvantages of Prior Art 1

[0036] Although PFC can guarantee RDMA lossless transmission, there are still the following problems in directly applying PFC on long-distance links across data center networks:

[0037] (1) Large BDP of long-haul link results in DCI switch with super large buffer:

[0038] When using PFC to implement RDMA lossless transmission on long-haul link, it is required that the DCI switch has a large enough buffer. When the queue length exceeds the XOFF threshold, the downstream DCI switch sends a pause frame to the upstream DCI switch. The worst case is that the upstream DCI switch sends long-haul flow packets at line speed, while the downstream DCI switch continues to drain at zero rate. In order to avoid the DCI switch buffer overflow and packet loss, the DCI switch headroom needs at least one BDP of buffer to prevent packet loss. When the queue length is less than the XON threshold, the downstream DCI switch sends a Resume frame to the upstream. The worst case is that the upstream DCI switch is completely paused, and the downstream DCI switch sends at line speed. In order to compensate for the link idle caused by the transmission delay of the RESUME message, the remaining buffer also needs one BDP to guarantee the throughput. Therefore, the DCI switch buffer should be set to 2 times the BDP size of the long-haul link.

[0039] However, the BDP of the long-haul link is too large, resulting in the need for the downstream DCI switch to allocate a super large buffer. For example, for a 400Gbps long-haul link with a length of 300km, the one-way delay is about 3ms, and the BDP is about 286MB, then the downstream DCI switch buffer needs to be at least about 572MB to meet the lossless normal transmission of the long-haul link. This is because the congestion detection of PFC is short-sighted, and the downstream DCI switch only reflects congestion based on the instantaneous queue length, which does not contain more detailed congestion information such as congestion trend. The congestion port of the downstream DCI switch cannot accurately determine the current network congestion state, and has to need a super large buffer space of 2 times the BDP to ensure that in the worst case it can still maintain high throughput.

[0040] (2) PFC suspends the entire priority in a coarse-grained manner, and the backpressure suspension mechanism is too aggressive.

[0041] The suspension mechanism of PFC is run by priority, not by flow. Since all long-haul flows flow through the DCI switch, once the long-haul link port of the DCI switch is suspended due to downstream congestion, all long-haul flows will be affected by the suspended port without distinction, and the data buffer cannot forward the message. At this time, the DCI switch enters the PFC deadlock state. In addition, using PFC also has the risk of unfairness, victim flow and congestion diffusion.

[0042] Prior art two:

[0043] DCQCN (Data Center Quantized Congestion Notification) is the default congestion control algorithm in data centers. It is the first end-to-end congestion control protocol with high practicality in RoCEv2 networks. It is improved by combining QCN and DCTCP, using ECN as congestion signal and adopting heuristic AIMD rate adjustment strategy. Its mechanism consists of three parts: CP algorithm deployed in switches performs congestion detection based on RED-ECN. When the queue length of the switch exceeds the specified threshold, the data packet will be marked as congestion to explicitly notify the receiver of network congestion. NP algorithm deployed in the receiving end generates a special CNP for the specified flow when it receives a data packet with CE congestion mark and sends it to the sending end RP with higher priority to notify it of network congestion. RP algorithm deployed in the sending end is responsible for adjusting the sending rate of each flow.

[0044] Through reasonable parameter configuration, DCQCN can achieve better end-to-end congestion control effect, maintain higher bandwidth utilization and lower queuing delay. DCQCN has been verified in some large data center networks and has achieved good results. It is widely used in various types of data center networks, including cloud computing, big data, artificial intelligence, etc., proving its feasibility in practical applications.

[0045] The disadvantages of the prior art two are:

[0046] Existing RDMA congestion control algorithms such as DCQCN achieve low delay and high throughput for data transmission in data centers. However, most existing algorithms are limited to internal network environment of data centers and have poor adaptability to long-distance links across data centers, especially the RTT time scale of hundreds of microseconds to milliseconds of long-distance links is much larger than that of internal network of data centers. Specifically as follows:

[0047] ① Due to the large RTT of long-distance links, when mixed traffic congestion occurs between long-distance flows and DC internal flows, the performance of both will be impaired:

[0048] Due to the long distance of the flow feedback loop, the queue of the congestion point continues to accumulate, and the DC internal flow experiences longer queuing delay. At the same time, the DC internal flow reacts faster to congestion, and the mixed flow congestion occurs first, and the whole speed reduction burden of responding to congestion is borne, finally leading to high tail delay of DC internal flow. At the same time, during the long-distance end-to-end CNP feedback, the long-distance flow still continues to accumulate the queue at the congestion point, and the excessive congestion control will make the sending rate of the long-distance flow source end decrease significantly in a multiplicative manner, and the bandwidth utilization rate of the long-distance flow decreases. Even after the congestion is removed, the AIMD linear speed-up needs a longer time to recover to the normal bandwidth, which suppresses the subsequent normal speed-up of the long-distance flow. In addition, considering that the buffer of the modern DC internal switch is usually shallow, in the mixed flow congestion scenario at the receiving end DC internal, if the long-distance flow fails to adjust the sending rate in time, the long-distance flow packets may fill the shallow buffer instantly when congestion occurs, and even send packets. The long-distance link needs a longer time to complete retransmission, which further reduces the transmission efficiency.

[0049] ②The granularity of congestion detection of the DCI switch is coarse, and the real congestion long-distance flow cannot be identified:

[0050] All long-distance flow transmissions will pass through the DCI switch. When queue accumulation occurs on the DCI switch, the DCI switch randomly marks all long-distance flows as congested, considering that all long-distance flows experience the same degree of congestion, even if the long-distance flow with a transmission rate lower than the fair bandwidth is marked as congested and reduced, which ultimately leads to the reduction of the overall throughput of the long-distance flow.

[0051] As shown in Figure 1 and 2 , the present application provides a flow congestion processing method for high-speed data center network, the steps of the method comprising:

[0052] Step S100, the receiving end switch receives the data packet from the long-distance link, and constructs a forwarding queue corresponding to the destination based on the destination of the data packet;

[0053] In the specific implementation process, a forwarding queue is constructed for each destination.

[0054] Step S200, obtaining the congestion notification packet fed back by the forwarding queue corresponding to the receiving end host connected to the receiving end switch, calculating the congestion degree value based on the congestion notification packet, and determining the flying byte threshold value based on the congestion degree value;

[0055] In the specific implementation process, the receiving end host determines whether to send the congestion notification packet based on the DCQCN (Data Center Quantized Congestion Notification) data center quantized congestion notification.

[0056] Step S300, calculating the flight bytes based on the bytes sent in each forwarding queue, comparing the flight bytes with the flight byte threshold, and determining whether the traffic of the corresponding forwarding queue is congested;

[0057] In the specific implementation, the flight bytes are the in-transit bytes in the process of transmission of the receiving end switch to the receiving end host.

[0058] Step S400, if the traffic of any forwarding queue is congested, controlling the congested traffic of the forwarding queue.

[0059] With the above scheme, in the processing of the long-distance link, the receiving end switch first constructs the forwarding queue corresponding to each destination according to the destination of the data packet, and calculates the flight bytes based on the bytes sent in each queue. In the scheme, the flight byte threshold can be updated in real time, and the comparison between the current flight byte threshold and the flight bytes is used to determine whether congestion occurs, which can react in advance in the flight stage of the bytes, realize congestion control in advance, and ensure the overall performance.

[0060] In some embodiments of the present application, in the step of obtaining the congestion notification message fed back by the forwarding queue corresponding to the receiving end host connected to the receiving end switch, calculating the congestion degree value based on the congestion notification message, and determining the flight byte threshold based on the congestion degree value, the initial value of the congestion degree value is 0, and the congestion degree value is increased by 1 for each congestion notification message received by a forwarding queue.

[0061] In the specific implementation, the upper limit value of the congestion degree value is set to 10, and the congestion degree value stops rising when the congestion degree value is the upper limit value.

[0062] In some embodiments of the present application, in the step of obtaining the congestion notification message fed back by the forwarding queue corresponding to the receiving end host connected to the receiving end switch, calculating the congestion degree value based on the congestion notification message, and determining the flight byte threshold based on the congestion degree value, if the receiving end switch receives the congestion notification message again within a preset time period after receiving the congestion notification message for a forwarding queue, the congestion degree value of the forwarding queue is increased by 1; and if the receiving end switch does not receive the congestion notification message within the preset time period after receiving the congestion notification message for a forwarding queue, the congestion degree value of the forwarding queue is reset to the initial value.

[0063] In some embodiments of the present application, in the step of obtaining the congestion notification message fed back by the forwarding queue corresponding to the receiving end host connected to the receiving end switch, calculating the congestion degree value based on the congestion notification message, and determining the flight byte threshold based on the congestion degree value, the flight byte threshold is calculated based on the following formula:

[0064] Threshold = BDP * (1 - degree / degreeT) ;

[0065] Wherein, Threshold represents a flight byte threshold, BDP represents a bandwidth delay product, degree represents a current congestion degree value, and degreeT represents an upper limit value of the congestion degree value.

[0066] By using the above scheme, the scheme can update the flight byte threshold through the real-time congestion degree value. When the congestion degree value rises, it indicates that congestion occurs continuously in a time period. In the scheme, the flight byte threshold gradually decreases along with the rising process of the congestion degree value, thereby realizing more frequent congestion control to reduce the congestion risk of the queue and guarantee the data transmission efficiency.

[0067] In some embodiments of the present application, in the step of calculating the number of flight bytes based on the number of bytes sent in each forwarding queue, the number of flight bytes is calculated based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the ACK message returned by the receiving end host.

[0068] In some embodiments of the present application, in the step of calculating the number of flight bytes based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the ACK message returned by the receiving end host, the number of received bytes Byte_rcv is determined based on the ACK message returned by the receiving end host, and the number of flight bytes is calculated based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the number of received bytes Byte_rcv.

[0069] In some embodiments of the present application, in the step of calculating the number of flight bytes based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the number of received bytes Byte_rcv, the number of flight bytes is calculated based on the following formula:

[0070] InflightByte = Byte_send - Byte_rcv; wherein InflightByte represents the number of flight bytes.

[0071] In some embodiments of the present application, in the step of comparing the number of flight bytes with the flight byte threshold to determine whether the traffic of the corresponding forwarding queue is congested, if the number of flight bytes is greater than the flight byte threshold, it is determined that the traffic of the corresponding forwarding queue is congested.

[0072] In some embodiments of the present application, in the step of controlling the congested traffic of any one of the forwarding queues, if the traffic of any one of the forwarding queues is congested, the output of the traffic of the forwarding queue is suspended, and when the number of flying bytes of the forwarding queue is not greater than the flying threshold, the data forwarding of the forwarding queue is resumed.

[0073] In summary, the RTT of long-distance links ranges from hundreds of microseconds to milliseconds, and its time scale is much larger than the RTT within a data center, which makes the deployment of RDMA across data center networks face higher delay challenges. On the one hand, higher delay results in much longer time required to recover lost packets, which means that it is necessary to reduce packet loss as much as possible during long-distance transmission, and this puts higher requirements on the buffer of DCI switches. On the other hand, the high delay of long-distance links also seriously affects the performance of various existing RDMA congestion control algorithms. Many existing data center RDMA congestion control schemes are designed on the premise of the short RTT of data centers, and are not suitable for the long-distance link large-RTT cross-data-center network. Specifically, when long-distance flows with high throughput and delay-sensitive intra-DC flows compete on the switches within a data center, if the mixed traffic congestion cannot be handled in time and appropriately, the transmission performance of both types of traffic will be impaired; in the present scheme, the receiving-end DCI switch limits the number of flying bytes for each destination, which can reduce the congestion scale when long-distance flows and receiving-end intra-DC flows conflict. Moreover, the receiving-end DCI switch further limits forwarding according to the congestion degree, and the lower the flying byte threshold for the corresponding destination, the more serious the congestion, so as to ensure that the congestion is eliminated as soon as possible.

[0074] The embodiment of the present application also provides a traffic congestion processing system for high-speed data center networks, which comprises a computer device, the computer device comprising a processor and a memory, the memory storing computer instructions, and the processor being configured to execute the computer instructions stored in the memory, so that the system implements the steps of the method as described above.

[0075] The embodiment of the present application also provides a computer readable storage medium storing a computer program, the computer program being configured to be executed by a processor to implement the steps of the traffic congestion processing method for high-speed data center networks as described above. The computer readable storage medium can be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0076] Those of ordinary skill in the art will appreciate that the various illustrative components, systems and methods described in connection with the embodiments disclosed herein can be implemented as hardware, software, or both. The particular implementation is dependent on the specific application and design constraints imposed on the overall system. Skilled persons can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application. When implemented in hardware, for example, the hardware can comprise an electronic circuit, an Application Specific Integrated Circuit (ASIC), a suitable firmware, a plug-in, a functional card, etc. When implemented in software, the elements of the application are the program or code segments to perform a specific task. The program or code segments can be stored in a machine-readable medium, or transmitted by a carrier wave as data signals over a transmission medium or communication link.

[0077] It is to be understood that the application is not limited to the particular configurations and processes described herein and shown in the drawings. For simplicity, detailed descriptions of known methods and apparatuses are omitted so as not to obscure the disclosure. In the above-described embodiments, several specific steps are described and illustrated as examples. However, the method processes of the present application are not limited to the specific steps described and illustrated, and the order of the steps can be changed, or other steps can be added, or replaced, or eliminated, depending on the application.

[0078] In the present application, features described and / or illustrated with respect to one embodiment can be used in the same or a similar way in one or more other embodiments, and / or in combination with or instead of features of other embodiments.

[0079] The above description is only preferred embodiments of the present application, and is not intended to limit the present application. The embodiments of the present application can be variously changed and modified by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the present application.

Claims

1. A method for processing traffic congestion in a high-speed data center network, characterized in that, The method comprises the following steps: The receiving end switch receives data packets from the long-distance link, and constructs a forwarding queue corresponding to the destination based on the destination of the data packets; The receiving end host connected to the receiving end switch feeds back a congestion notification packet to the forwarding queue, and calculates a congestion degree value based on the congestion notification packet. The initial value of the congestion degree value is 0. For a forwarding queue, the congestion degree value is increased by 1 when a congestion notification packet is received. If the receiving end switch receives another congestion notification packet within a preset time period after receiving a congestion notification packet for a forwarding queue, the congestion degree value of the forwarding queue is increased by 1. If the receiving end switch does not receive a congestion notification packet within a preset time period after receiving a congestion notification packet for a forwarding queue, the congestion degree value of the forwarding queue is reset to the initial value. The flight byte threshold is calculated based on the following formula: Threshold = BDP * (1-degree / degreeT); Wherein, Threshold represents the flight byte threshold, BDP represents the bandwidth delay product, degree represents the current congestion degree value, and degreeT represents the upper limit value of the congestion degree value; The number of flight bytes is calculated based on the number of bytes sent in each forwarding queue, and the number of flight bytes and the flight byte threshold are compared to determine whether the traffic of the corresponding forwarding queue is congested. If the traffic of any forwarding queue is congested, the congestion traffic of the forwarding queue is controlled.

2. The method for processing traffic congestion of a high-speed data center network according to claim 1, wherein, In the step of calculating the number of flight bytes based on the number of bytes sent in each forwarding queue, the number of flight bytes is calculated based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the ACK packet returned by the receiving end host.

3. The method for processing traffic congestion of a high-speed data center network according to claim 2, wherein, In the step of calculating the number of flight bytes based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the ACK packet returned by the receiving end host, the number of received bytes Byte_rcv is determined based on the ACK packet returned by the receiving end host, and the number of flight bytes is calculated based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the number of received bytes Byte_rcv.

4. The method for processing traffic congestion of a high-speed data center network according to claim 3, wherein, In the step of calculating the number of flight bytes based on the number of bytes sent by the receiving end DCI switch to the destination Byte_send and the number of received bytes Byte_rcv, the number of flight bytes is calculated based on the following formula: InflightByte = Byte_send - Byte_rcv; wherein InflightByte represents the number of flight bytes.

5. The method for processing traffic congestion of a high-speed data center network according to claim 1, wherein, In the step of comparing the number of flight bytes with the flight byte threshold to determine whether the traffic of the corresponding forwarding queue is congested, if the number of flight bytes is greater than the flight byte threshold, it is determined that the traffic of the corresponding forwarding queue is congested.

6. The method for processing traffic congestion of a high-speed data center network according to claim 1 or 5, wherein, In the step of controlling the congestion traffic of any one of the forwarding queues, if the traffic of any one of the forwarding queues is congested, the traffic output of the forwarding queue is suspended, and when the number of flying bytes of the forwarding queue is not greater than the flying threshold, the data forwarding of the forwarding queue is resumed.

7. A traffic congestion handling system for high-speed data center networks, characterized in that, The system comprises a computer device, the computer device comprises a processor and a memory, the memory stores computer instructions, and the processor is configured to execute the computer instructions stored in the memory, and the system implements the steps of the method as claimed in any one of claims 1-6 when the computer instructions are executed by the processor.

Images