Congestion control method based on time delay perception and adaptive bandwidth adjustment

Abstract

The invention relates to a congestion control method based on time delay perception and adaptive bandwidth adjustment. The congestion control method comprises the following steps: 1) monitoring network delay in real time according to a window refreshing algorithm based on packet triggering, and making a sending window refreshing request at a sending end; 2) monitoring network delay in real time according to a window resetting algorithm triggered based on a sending task, and proposing a sending window resetting request at a sending end; and 3) according to a dual-redundancy window refresh decision algorithm, determining whether to respond to a refresh / reset request of the sending window of the sending end, and executing an effective refresh / reset operation of the sending window to cope with the change of the network condition. According to the method, the network delay is monitored in real time through cooperation of the two mutually redundant window refreshing algorithms, and the data sending window is dynamically adjusted according to the monitored delay, so that the transmission efficiency is optimized, and the network congestion is reduced.

Description

Technical Field

[0001] The present invention relates to the field of computer networks, and in particular to a congestion control method based on delay perception and adaptive bandwidth regulation. Background Art

[0002] With the development of high-performance computing (HPC), cloud computing and large-scale data centers, the demand for high efficiency, low latency and high throughput of network transmission has become more and more urgent. The traditional TCP / IP protocol cannot effectively cope with network congestion and latency fluctuations when facing large-scale parallel computing and high-throughput application scenarios. Therefore, Remote Direct Memory Access (RDMA) technology came into being.

[0003] RDMA allows direct memory data transfer between servers, bypassing the operating system kernel and reducing the involvement of the processor, thereby significantly reducing latency and CPU usage in data transmission. RoCEv2 (RDMA over ConvergedEthernet v2) is one of the evolutions of RDMA technology, which implements efficient data transmission based on traditional Ethernet. However, RoCEv2 still faces the challenge of congestion control in a high-load network environment, especially how to optimize the utilization of network bandwidth while ensuring low latency. Although current congestion control mechanisms, such as DCQCN (Data Center Quantized Congestion Notification), have solved the congestion problem to a certain extent, they still have problems such as delayed response and untimely bandwidth adjustment when facing complex network topologies and dynamic traffic changes. This leads to fluctuations in network latency, which in turn affects application performance and user experience. Summary of the invention

[0004] In order to solve the problems of transmission delay fluctuation and congestion control response lag in the existing RoCEv2 protocol network under high load conditions in the background technology, the present invention proposes a dual-redundancy window refresh congestion control method based on delay perception and adaptive bandwidth adjustment congestion control. The present invention cooperates through two mutually redundant window refresh algorithms, monitors network delay in real time, and dynamically adjusts the data sending window according to the monitored delay, thereby optimizing transmission efficiency and reducing network congestion.

[0005] The technical solution of the present invention is: the present invention is a congestion control method based on delay perception and adaptive bandwidth adjustment, and its special feature is that the control method comprises the following steps:

[0006] 1) Monitor network delay in real time based on the packet-triggered window refresh algorithm and make a send window refresh request at the sender;

[0007] 2) Monitor network delay in real time based on the window reset algorithm triggered by the sending task and make a sending window reset request at the sending end;

[0008] 3) Determine whether to respond to the sender's send window refresh / reset request based on the dual-redundancy window refresh decision algorithm, and perform effective send window refresh / reset operations to cope with changes in network conditions.

[0009] Further, the specific steps of step 1) are as follows:

[0010] 1.1) The sending engine at the sending end sends a congestion control request (CCREQ-a) message carrying the sending time; when the congestion control engine at the receiving end receives the CCREQ-a message, it returns a congestion control confirmation (CCACK-a) message carrying the sending time of the CCREQ-a message;

[0011] 1.2) After receiving the CCACK-a message, the sender calculates the delay of the data packet and sends the next CCREQ-a message; the delay calculation method of the data packet is:

[0012] RTT=rdma_time-ccack.send_time

[0013] Among them, RTT is the delay of the latest received data packet, cccack.send_time is the time when the sender sends CCREQ-a, and rdma_time is the time when the sender receives the CCACK-a message;

[0014] 1.3) The sender refreshes the RTTmin record; RTTmin is the minimum delay of the sender;

[0015] 1.4) The sender calculates the send window pre-refresh value (hacc_twin_a) based on the RTT obtained in step 1.3), and then makes a send window refresh request.

[0016] Further, the specific steps of step 1.4) are as follows:

[0017] 1.4.1) The sender calculates two thresholds based on RTTmin, namely RTThigh and RTTlow; the calculation method is:

[0018] RTThigh=RTTmin*rttmin_highth

[0019] RTTlow=RTTmin*rttmin_lowth

[0020] Among them, rttmin_highth and rttmin_lowth are coefficient factors; used to adjust the values ​​of RTThigh and RTTlow;

[0021] 1.4.2) The sender compares the RTT obtained in step 1.3) with the RTThigh and RTTlow obtained in step 1.4.1) to determine the pre-refresh value of the sending window. The calculation method is:

[0022] If RTT is greater than or equal to RTThigh,

[0023] Then hacc_win_a = (the difference in received data between two ccack-a) + window fixed increment - window dynamic reduction value;

[0024] If RTT is between RTThigh and RTTlow,

[0025] Then hacc_win_a=(the difference of the received data between two ccack-a)+window fixed increment;

[0026] If RTT is less than or equal to RTTlow,

[0027] Then hacc_win_a = (the difference between the received data of two ccack-a) + the fixed increment of the window + the dynamic increment of the window;

[0028] Where hacc_win_a is the value of the send window pre-refresh;

[0029] 1.4.3) Correct the send window pre-refresh value to ensure that it does not exceed the upper and lower thresholds of the send window; the calculation method is:

[0030] If hacc_win_a is less than or equal to hacc_win_min,

[0031] Then hacc_win_a=hacc_win_min;

[0032] If hacc_win_a is greater than or equal to hacc_win_max,

[0033] Then hacc_win_a=hacc_win_max;

[0034] If hacc_win_a is between hacc_win_min and hacc_win_max, the value of hacc_win_a remains unchanged;

[0035] 1.4.4) The sender makes a send window refresh request; wherein the send window refresh value is the hacc_win_a obtained in step 1.4.3).

[0036] Further, the specific steps of step 2) are as follows:

[0037] 2.1) The sending end counts the doorbell counter of the sending mechanism and stores it in db_cnt. When sending a service packet, it counts according to granularity A; when failing to send a service packet, it counts according to granularity B;

[0038] 2.2) When db_cnt in step 2.1) reaches the set threshold, the sending engine will periodically send a congestion control request (CCREQ-b) message carrying the sending time; when the congestion control engine at the receiving end receives the CCREQ-b message, it will return a congestion control confirmation (CCACK-b) message carrying the CCREQ-b message sending time corresponding to the message;

[0039] 2.3) After receiving the CCACK-b message, the sender calculates the data packet delay (RTT) according to the method in step 1.2);

[0040] 2.4) The sender calculates the pre-reset value of the sending window (hacc_twin_b) according to the RTT obtained in step 2.3) and makes a sending window reset request.

[0041] Further, the specific steps of step 2.4) are as follows:

[0042] 2.4.1) The sender refreshes the RTTmin record;

[0043] Among them, RTTmin is the minimum delay of the sender;

[0044] 2.4.2) The sender calculates the window reset threshold RTT_winrste_min based on RTTmin; the calculation method is:

[0045] RTT_winrste_min=RTTmin*hacc_winrste_trrmin

[0046] Among them, hacc_winrste_trrmin is the parameter required to calculate the window reset threshold;

[0047] 2.4.3) The sender determines the value of the send window reset by judging the RTT obtained in step 2.3) and the send window reset threshold RTT_winrste_min obtained in step 2.4.2); the calculation method is:

[0048] If RTT is greater than or equal to RTT_winrste_min,

[0049] Then hacc_twin_b=hacc_winrste_lowwin;

[0050] If RTT is less than RTT_winrste_min,

[0051] Then hacc_twin_b=hacc_winrste_highwin;

[0052] Among them, hacc_winrste_lowwin is the window reset small window value, and hacc_winrste_highwin is the window reset large window value;

[0053] 2.4.4) The sender makes a request to reset the sending window; wherein the sending window reset value is the hacc_win_b obtained in step 2.4.3).

[0054] Further, the specific steps of step 3) are as follows:

[0055] 3.1) The sender receives the send window refresh / reset request of step 1) and step 2);

[0056] 3.2) The sending window is finally refreshed / reset according to the dual-redundancy window refresh decision algorithm. The algorithm stipulates that the first request outside the settlement window is responded to; wherein, the calculation formula of the settlement window is as follows:

[0057] Settlement window = the time when the last valid congestion control confirmation message was received + RTTmin + window fixed time increment.

[0058] The present invention provides a congestion control method based on delay perception and adaptive bandwidth regulation, which includes two window refresh algorithms with different triggering mechanisms: a window refresh algorithm based on packet triggering and a window refresh reset algorithm based on sending task triggering. The two work together to ensure real-time perception and regulation of link congestion. In order to avoid frequent refreshing of the sending window, a dual-redundancy window refresh decision algorithm determines whether to respond to the refresh / reset request of the sending window of the sender, ensuring that the window refresh operation is only performed when necessary. The present invention can improve network transmission efficiency, reduce delays, enhance network stability and reliability, and is suitable for high-load or dynamically changing network environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 It is a schematic diagram of the method flow of the present invention. DETAILED DESCRIPTION

[0060] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0061] See also Figure 1 The steps of a specific embodiment of the congestion control method based on delay perception and adaptive bandwidth adjustment of the present invention are as follows:

[0062] 1) The sender monitors the network delay in real time by sending congestion control requests (CCREQ-a) and receiving confirmation messages (CCACK-a), calculates and updates the minimum delay (RTTmin), and finally makes a window refresh request.

[0063] 2) The sender counts the doorbell counter of the sending mechanism at a certain granularity and when the count reaches the threshold, the sender periodically sends a congestion control request (CCREQ-b), calculates the delay based on the received acknowledgment message (CCACK-b), and makes a window reset request.

[0064] 3) Determine whether to respond to the refresh / reset request of steps S1 and S2 according to the dual-redundancy window refresh decision algorithm. Perform effective send window refresh and reset operations to cope with changes in network conditions.

[0065] Wherein, the specific method of step 1) is as follows:

[0066] 1.1) The sending engine at the sending end sends a congestion control request (CCREQ-a) message carrying the sending time; when the congestion control engine at the receiving end receives the CCREQ-a message, it returns a congestion control confirmation (CCACK-a) message carrying the sending time of the CCREQ-a corresponding to the message.

[0067] 1.2) After receiving the CCACK-a message, the sender calculates the delay of the data packet and sends the next CCREQ-a message.

[0068] The delay of the data packet is calculated as follows:

[0069] RTT=rdma_time-ccack.send_time

[0070] Among them, RTT is the delay of the latest received data packet, cccack.send_time is the time when the sender sends CCREQ-a, and rdma_time is the time when the sender receives the CCACK-a message.

[0071] 1.3) The sender refreshes the RTTmin record;

[0072] Among them, RTTmin is the minimum delay of the sender.

[0073] 1.4) The sender calculates the send window pre-refresh value (hacc_twin_a) based on the RTT obtained in step 1.3), and then makes a send window refresh request.

[0074] The specific steps of step 1.4) are as follows:

[0075] 1.4.1) The sender calculates two thresholds based on RTTmin, namely RTThigh and RTTlow; the calculation method is:

[0076] RTThigh=RTTmin*rttmin_highth

[0077] RTTlow=RTTmin*rttmin_lowth

[0078] Among them, rttmin_highth and rttmin_lowth are coefficient factors; used to adjust the values ​​of RTThigh and RTTlow;

[0079] 1.4.2) The sender compares the RTT obtained in step 1.3) with the RTThigh and RTTlow obtained in step 1.4.1) to determine the value of the send window pre-refresh, which is calculated as follows:

[0080] If RTT is greater than or equal to RTThigh,

[0081] Then hacc_win_a = (the difference in received data between two ccack-a) + window fixed increment - window dynamic reduction value;

[0082] If RTT is between RTThigh and RTTlow,

[0083] Then hacc_win_a=(the difference of the received data between two ccack-a)+window fixed increment;

[0084] If RTT is less than or equal to RTTlow,

[0085] Then hacc_win_a = (the difference between the received data of two ccack-a) + the fixed increment of the window + the dynamic increment of the window;

[0086] Where hacc_win_a is the value of the send window pre-refresh;

[0087] 1.4.3) Correct the send window pre-refresh value to ensure that it does not exceed the upper and lower thresholds of the send window; the calculation method is:

[0088] If hacc_win_a is less than or equal to hacc_win_min,

[0089] Then hacc_win_a=hacc_win_min;

[0090] If hacc_win_a is greater than or equal to hacc_win_max,

[0091] Then hacc_win_a=hacc_win_max;

[0092] If hacc_win_a is between hacc_win_min and hacc_win_max, the value of hacc_win_a remains unchanged;

[0093] 1.4.4) The sender makes a send window refresh request; wherein the send window refresh value is the hacc_win_a obtained in step 1.4.3).

[0094] The specific method of step 2) is as follows:

[0095] 2.1) The sending end counts the doorbell counter of the sending mechanism and stores it in db_cnt. When sending a service packet, it counts according to granularity A; when failing to send a service packet, it counts according to granularity B.

[0096] 2.2) When db_cnt in step 2.1) reaches the set threshold, the sending engine will periodically send a congestion control request (CCREQ-b) message carrying the sending time. When the congestion control engine at the receiving end receives the CCREQ-b message, it will return a congestion control confirmation (CCACK-b) message carrying the sending time of the message.

[0097] 2.3) After receiving the CCACK-b message, the sender calculates the data packet delay (RTT) according to the method in step 1.2).

[0098] 2.4) The sender calculates the pre-reset value of the sending window (hacc_twin_b) according to the RTT obtained in step 2.3) and makes a sending window reset request.

[0099] The specific steps of step 2.4) are as follows:

[0100] 2.4.1) The sender refreshes the RTTmin record;

[0101] Among them, RTTmin is the minimum delay of the sender;

[0102] 2.4.2) The sender calculates the window reset threshold RTT_winrste_min based on RTTmin; the calculation method is:

[0103] RTT_winrste_min=RTTmin*hacc_winrste_trrmin

[0104] Among them, hacc_winrste_trrmin is the parameter required to calculate the window reset threshold;

[0105] 2.4.3) The sender determines the value of the send window reset by judging the RTT obtained in step 2.3) and the send window reset threshold RTT_winrste_min obtained in step 2.4.2); the calculation method is:

[0106] If RTT is greater than or equal to RTT_winrste_min,

[0107] Then hacc_twin_b=hacc_winrste_lowwin;

[0108] If RTT is less than RTT_winrste_min,

[0109] Then hacc_twin_b=hacc_winrste_highwin;

[0110] Among them, hacc_winrste_lowwin is the window reset small window value, and hacc_winrste_highwin is the window reset large window value;

[0111] 2.4.4) The sender makes a request to reset the sending window; wherein the sending window reset value is the hacc_win_b obtained in step 2.4.3).

[0112] The specific method of step 3) is as follows:

[0113] 3.1) The sender receives the send window refresh / reset request of step 1) and step 2);

[0114] 3.2) The sending window is finally refreshed / reset according to the dual-redundancy window refresh decision algorithm. The algorithm stipulates that the first request outside the settlement window is responded to; wherein, the calculation formula of the settlement window is as follows:

[0115] Settlement window = the time when the last valid congestion control confirmation message was received + RTTmin + window fixed time increment.

[0116] The above are only specific embodiments disclosed in the present invention, but the protection scope of the present invention is not limited thereto. The protection scope of the present invention shall be based on the protection scope of the claims.

[0117] The content of the present invention and the technical content not specifically described in the above embodiments are the same as the prior art.

[0118] The present invention is not limited to the above embodiments, and all of the contents of the present invention can be implemented and have the above good effects.

Claims

1. A congestion control method based on delay perception and adaptive bandwidth adjustment, characterized in that: The control method comprises the following steps: 1) Monitor network delay in real time based on the packet-triggered window refresh algorithm and make a send window refresh request at the sender; 2) Monitor network delay in real time based on the window reset algorithm triggered by the sending task and make a sending window reset request at the sending end; 3) Determine whether to respond to the sender's send window refresh / reset request based on the dual-redundancy window refresh decision algorithm, and perform effective send window refresh / reset operations to cope with changes in network conditions.

2. The congestion control method based on delay perception and adaptive bandwidth adjustment according to claim 1, characterized in that: The specific steps of step 1) are as follows: 1.1) The sending engine at the sending end sends a congestion control request (CCREQ-a) message carrying the sending time; when the congestion control engine at the receiving end receives the CCREQ-a message, it returns a congestion control confirmation (CCACK-a) message carrying the sending time of the CCREQ-a message; 1.2) After receiving the CCACK-a message, the sender calculates the delay of the data packet and sends the next CCREQ-a message; the delay calculation method of the data packet is: RTT=rdma_time-ccack.send_time Among them, RTT is the delay of the latest received data packet, cccack.send_time is the time when the sender sends CCREQ-a, and rdma_time is the time when the sender receives the CCACK-a message; 1.3) The sender refreshes the RTTmin record; RTTmin is the minimum delay of the sender; 1.4) The sender calculates the send window pre-refresh value (hacc_twin_a) based on the RTT obtained in step 1.3), and then makes a send window refresh request.

3. The congestion control method based on delay perception and adaptive bandwidth adjustment according to claim 2 is characterized in that: The specific steps of step 1.4) are as follows: 1.4.1) The sender calculates two thresholds based on RTTmin, namely RTThigh and RTTlow; the calculation method is: RTThigh=RTTmin*rttmin_highth RTTlow=RTTmin*rttmin_lowth Among them, rttmin_highth and rttmin_lowth are coefficient factors; used to adjust the values ​​of RTThigh and RTTlow; 1.4.2) The sender compares the RTT obtained in step 1.3) with the RTThigh and RTTlow obtained in step 1.4.1) to determine the value of the send window pre-refresh, which is calculated as follows: If RTT is greater than or equal to RTThigh, Then hacc_win_a = (the difference in received data between two ccack-a) + window fixed increment - window dynamic reduction value; If RTT is between RTThigh and RTTlow, Then hacc_win_a=(the difference of the received data between two ccack-a)+window fixed increment; If RTT is less than or equal to RTTlow, Then hacc_win_a = (the difference between the received data of two ccack-a) + the fixed increment of the window + the dynamic increment of the window; Where hacc_win_a is the value of the send window pre-refresh; 1.4.3) Correct the send window pre-refresh value to ensure that it does not exceed the upper and lower thresholds of the send window; the calculation method is: If hacc_win_a is less than or equal to hacc_win_min, Then hacc_win_a=hacc_win_min; If hacc_win_a is greater than or equal to hacc_win_max, Then hacc_win_a=hacc_win_max; If hacc_win_a is between hacc_win_min and hacc_win_max, the value of hacc_win_a remains unchanged; 1.4.4) The sender makes a send window refresh request; wherein the send window refresh value is the hacc_win_a obtained in step 1.4.3).

4. The congestion control method based on delay perception and adaptive bandwidth adjustment according to claim 2 or 3, characterized in that: The specific steps of step 2) are as follows: 2.1) The sending end counts the doorbell counter of the sending mechanism and stores it in db_cnt. When sending a service packet, it counts according to granularity A; when failing to send a service packet, it counts according to granularity B; 2.2) When db_cnt in step 2.1) reaches the set threshold, the sending engine will periodically send a congestion control request (CCREQ-b) message carrying the sending time; when the congestion control engine at the receiving end receives the CCREQ-b message, it will return a congestion control confirmation (CCACK-b) message carrying the CCREQ-b message sending time corresponding to the message; 2.3) After receiving the CCACK-b message, the sender calculates the data packet delay (RTT) according to the method in step 1.2); 2.4) The sender calculates the pre-reset value of the sending window (hacc_twin_b) according to the RTT obtained in step 2.3) and makes a sending window reset request.

5. The congestion control method based on delay perception and adaptive bandwidth adjustment according to claim 4 is characterized in that: The specific steps of step 2.4) are as follows: 2.4.1) The sender refreshes the RTTmin record; in, RTTmin is the minimum delay at the sending end; 2.4.2) The sender calculates the window reset threshold RTT_winrste_min based on RTTmin; the calculation method is: RTT_winrste_min=RTTmin*hacc_winrste_trrmin in, hacc_winrste_trrmin is the parameter required to calculate the window reset threshold; 2.4.3) The sender determines the value of the send window reset by judging the RTT obtained in step 2.3) and the send window reset threshold RTT_winrste_min obtained in step 2.4.2); the calculation method is: If RTT is greater than or equal to RTT_winrste_min, Then hacc_twin_b=hacc_winrste_lowwin; If RTT is less than RTT_winrste_min, Then hacc_twin_b=hacc_winrste_highwin; Among them, hacc_winrste_lowwin is the window reset small window value, and hacc_winrste_highwin is the window reset large window value; 2.4.4) The sender makes a request to reset the sending window; wherein the sending window reset value is the hacc_win_b obtained in step 2.4.3).

6. The congestion control method based on delay perception and adaptive bandwidth adjustment according to claim 5, characterized in that: The specific steps of step 3) are as follows: 3.1) The sender receives the send window refresh / reset request of step 1) and step 2); 3.2) The sending window is finally refreshed / reset according to the dual-redundancy window refresh decision algorithm, and the algorithm stipulates that the first request outside the settlement window is responded to; wherein, The calculation formula of the settlement window is as follows: Settlement window = the time when the last valid congestion control confirmation message was received + RTTmin + window fixed time increment.

Images