Flow control method based on transmission cache and processing time delay
Through the flow control method of calculating the congestion window value based on transmission cache and processing delay in a high-performance AI computing environment, the problem that existing TCP/IP networks cannot meet microsecond latency and high throughput is solved, and more efficient and economical data transmission and processing capabilities are achieved.
Patent Information
- Application Number
- CN202510390708.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-31
- Publication Date
- 2025-06-20
AI Technical Summary
Existing TCP/IP networks cannot meet the requirements of microsecond latency and high throughput in high-performance AI computing environments, and traditional congestion control algorithms do not perform well in low-latency and high-bandwidth environments.
The traffic control method based on transmission cache and processing delay is adopted. By calculating the congestion window value according to the SRAM buffer size and environmental impact factor of the sending and receiving ends when the connection is established, instead of the traditional TCP dynamically adjusting the congestion window mechanism.
It reduces the dependence of the transmission protocol on the CPU, simplifies the control process, improves data throughput and transmission efficiency, and reduces message transmission delay, and is suitable for high-performance AI computing environments.
Smart Images

Figure CN120186092A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of network congestion control, and in particular, to a traffic control method based on transmission buffer and processing delay. Background Art
[0002] With the wide deployment of artificial intelligence applications, the network latency requirement has dropped from the millisecond level to the microsecond level. The millisecond-level latency of traditional TCP / IP networks cannot meet the extreme pursuit of AI computing for data processing speed and efficiency.
[0003] TCP congestion control mainly relies on four key algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. These algorithms work together to adapt to changes in network conditions.
[0004] Slow Start: At the beginning of a TCP connection establishment, the Slow Start algorithm exponentially increases the size of the sending window until network congestion occurs or a preset Slow Start threshold is reached.
[0005] Congestion Avoidance: When the size of the sending window exceeds the Slow Start threshold, the Congestion Avoidance algorithm takes over. At this time, the window size linearly increases to increase the transmission rate in a more conservative manner.
[0006] Fast Retransmit: When the receiver detects an out-of-order TCP segment, it sends duplicate ACKs (acknowledgment replies). After the sender receives three duplicate ACKs, it immediately retransmits the lost data packet instead of waiting for the retransmission timer to expire.
[0007] Fast Recovery: Used in conjunction with Fast Retransmit, the Fast Recovery algorithm reduces the size of the congestion window when packet loss occurs, but the reduction amplitude is less than the Slow Start threshold to quickly recover the transmission rate.
[0008] TCP uses mechanisms such as Slow Start, congestion window, and timeout retransmission to control congestion, and the window changes are as Figure 4 shown.
[0009] In addition to these basic algorithms, there are also various improved congestion control algorithms, such as Reno, Vegas, BIC, CUBIC, etc. They perform differently in different network environments and aim to provide better performance and adaptability. For example, the CUBIC algorithm is one of the currently widely used congestion control algorithms, and it performs well in high bandwidth-delay (BDP) network environments.
[0010] Each of the four algorithms has its own advantages and limitations and is suitable for different network environments. For example, Reno is the most basic algorithm, suitable for most network environments, but may have a slower response in fast networks. Vegas uses delay as a congestion signal and is suitable for high-bandwidth delay product networks. BIC and CUBIC are designed for high-speed networks, where CUBIC pays particular attention to RTT fairness and is suitable for high-speed, long-distance networks. However, the above algorithms are not applicable to high-performance and AI computing environments with low latency and high bandwidth due to complex protocol processing and high overhead, and a new congestion control protocol is needed.
[0011] In high-performance AI computing environments, congestion control has extreme requirements for low latency and high throughput, including the following aspects:
[0012] Low-latency design: Provide latency at the microsecond level, which is crucial for real-time AI processing and training models;
[0013] Reduce dependence on the CPU, simplify control, and thus improve efficiency and performance.
[0014] None of the above algorithms are applicable in high-performance AI computing environments.
[0015] With the development of network technology, new congestion control algorithms are constantly being proposed to cope with more complex network environments, such as data center networks, AI computing networks, etc.
[0016] However, how to better maximize network throughput and reduce latency while ensuring network stability remains an issue that requires in-depth research and solution. Summary of the Invention
[0017] To overcome the deficiencies in the background technology, the present invention provides a traffic control method based on transmission buffer and processing delay.
[0018] To achieve the above invention purpose, the present invention adopts the following technical solutions:
[0019] In a first aspect, the present invention provides a traffic control method based on transmission buffer and processing delay, for a sending end, including the following steps:
[0020] S11. The sending end calculates a first congestion window value according to the size of the sending SRAM buffer;
[0021] S12. Send a SYN packet, and the SYN packet includes the first congestion window value;
[0022] S13. Obtain the SYN-ACK packet sent by the receiving end; the SYN-ACK includes a third congestion window value, and the third congestion window value is the smaller value between the second congestion window value calculated by the receiving end according to the size of the receiving SRAM buffer and the first congestion window value;
[0023] S14. Calculate a fourth congestion window value according to the RTT time in the received SYN-ACK packet;
[0024] S15. Take the smaller value between the third congestion window value and the fourth congestion window value as the fifth congestion window value;
[0025] S16. The sending end sends data packets with the fifth congestion window value.
[0026] Specifically, the calculation formula of the first congestion window value in step S11 is as follows:
[0027]
[0028] Where cwnd_size_1 is the first congestion window value; MSS is the maximum segment size of the network interface; SRAM_send is the size of the sending SRAM buffer; λ s is the influence factor of the sending end environment.
[0029] Specifically, the calculation formula of the fourth congestion window value in step S14 is as follows:
[0030]
[0031] Where cwnd_size_4 is the fourth congestion window value; net_rate is the transmission rate of the network; λ is the influence factor of the network environment.
[0032] Specifically, before step S16, it further includes: packing the fifth congestion window value into an ACK packet and sending it to the receiving end.
[0033] Specifically, the congestion window value in the SYN-ACK packet in step S16 is the congestion window value returned by the receiving end.
[0034] Specifically, the method further includes: S17. Enter the data packet sending stage, and the congestion window value is no longer adjusted.
[0035] Specifically, step S17 further includes: during data sending, when the SRAM buffer is full, the sending will stop, and packet loss is handled by retransmitting the data saved in the SRAM buffer.
[0036] Second aspect, the present invention provides a traffic control method based on transmission buffer and processing delay, for the receiving end, including the following steps:
[0037] S21. Receive a SYN packet; the SYN packet contains a first congestion window value; the first congestion window value is calculated by the sending end according to the size of the sending SRAM buffer;
[0038] S22. The receiving end calculates a second congestion window value according to the size of the receiving SRAM buffer;
[0039] S23. Take the smaller value of the first congestion window value and the second congestion window value as the third congestion window value, and send the third congestion window value to the receiving end;
[0040] S24. Receive the ACK packet sent by the sending end, and use the fifth congestion window value contained in the ACK packet to receive data packets.
[0041] Specifically, the calculation formula of the second congestion window value in step S22 is as follows:
[0042]
[0043] Where cwnd_size_2 is the second congestion window value; MSS is the maximum segment length of the network interface; SRAM_recv is the size of the receiving SRAM buffer; λ r is the receiving end environment impact factor.
[0044] The step of "and send the third congestion window value to the receiving end" in step S23 is specifically: pack the third congestion window value into a SYN-ACK packet and send it to the sending end.
[0045] Specifically, λ, λ s , λ r takes values in (0, 1].
[0046] The present invention provides a traffic control method based on transmission buffer and processing delay. Instead of using the traditional TCP dynamic congestion window adjustment mechanism, it determines the window size according to the SRAM buffer sizes in the hardware of the client and the server at the time of connection establishment, and simultaneously considers the buffer utilization rates of the receiving end and the sending end. The present invention reduces the dependence of the transmission protocol on the CPU, has simpler control, higher data throughput rate, reduces the packet transmission delay, and thus improves the efficiency and performance of data transmission.
[0047] In addition, when the buffer is full, the sending stops, and packet loss is handled by retransmitting the data saved in the SRAM buffer. This method eliminates the need for additional sending credits and reduces the complexity of the network switch.
[0048] In addition, the present invention provides a traffic control method based on transmission cache and processing delay, which is oriented to high-performance AI computing requirements and named congestion control algorithm Xpress (Express, fast). It controls congestion based on source-side control strategies and local link levels, uses a fixed-size SRAM buffer, and simultaneously considers the buffer utilization rates of both the receiving and sending ends. Instead of the dynamic congestion window of TCP, it helps reduce the complexity of congestion management, reduces the dependence of the transmission protocol on the CPU, unifies the congestion control window, helps achieve more consistent performance in low-latency networks, optimizes the low-latency and low-packet-loss environment in supercomputer networks, reduces packet transmission delay, thereby effectively breaking through the bottleneck of the existing technology and realizing more efficient, more economical, and more reliable data transmission and processing capabilities, laying a solid foundation for the continuous innovation in the field of AI.
[0049] In addition, the congestion control algorithm of the traffic control method based on transmission cache and processing delay provided by the present invention is similar to TCP. It handles congestion by simply discarding packets. Xpress uses fast retransmission and fast recovery to manage network congestion and does not adopt congestion control algorithms such as slow start and congestion avoidance. Compared with the conventional congestion control algorithms of TCP, the congestion control provided by the present invention is simpler, has a higher data throughput rate, reduces packet transmission delay, and thus improves the efficiency and performance of data transmission. BRIEF DESCRIPTION OF THE DRAWINGS
[0050] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0051] Figure 1 It is a schematic diagram of a traffic control method based on transmission cache and processing delay (sending end) provided by an embodiment of the present invention;
[0052] Figure 2 It is a schematic diagram of a traffic control method based on transmission cache and processing delay (receiving end) provided by an embodiment of the present invention;
[0053] Figure 3 It is a schematic diagram of the TCP congestion window negotiation process of a traffic control method based on transmission cache and processing delay provided by an embodiment of the present invention;
[0054] Figure 4 It is a schematic diagram of the conventional change of the TCP congestion window provided by an embodiment of the present invention;
[0055] Figure 5 It is a schematic diagram of the change of the TCP congestion window based on transmission buffer and processing delay provided by an embodiment of the present invention. Specific implementation manners
[0056] The present invention can be explained in detail through the following embodiments. The purpose of providing the present invention is to protect all technical improvements within the scope of the present invention. In the description of the present invention, it should be understood that if there are terms such as "upper", "lower", "front", "rear", "left", "right", etc. indicating the orientation or position relationship, they are only corresponding to the drawings of the present application for the convenience of describing the present invention, rather than indicating or implying that the device or element referred to must have a specific orientation.
[0057] Embodiment 1
[0058] This embodiment provides a flow control method based on transmission buffer and processing delay for data transmission between a sender and a receiver. Among them, both the sender and the receiver can be a terminal, a server, etc. The sender is the sender of the transmitted data, and the receiver is the receiver of the transmitted data. The sender and the receiver can communicate with each other.
[0059] During the establishment and data transmission process of a TCP (Transmission Control Protocol) connection, SYN, SYN-ACK, ACK, FIN, FIN-ACK are control flags of different types of TCP segments, and they each have different meanings:
[0060] 1) SYN (Synchronize Sequence Numbers): Synchronize sequence numbers, which are used to synchronize the initial sequence numbers of both parties when establishing a connection.
[0061] 2) SYN-ACK (Synchronize Acknowledgment): Respond to the synchronize sequence number and confirm the SYN segment of the client. During the TCP three-way handshake process, when the server receives a SYN (Synchronize) segment from the client, it will send a SYN-ACK segment as a response.
[0062] 3) ACK (Acknowledgment): The ACK segment is used to confirm the received TCP segment. Throughout the process of connection establishment and data transmission, the ACK segment is used to tell the sender that the receiver has received a specific data packet.
[0063] 4) FIN (Finish): The FIN segment is used to end a TCP connection. When the sender completes the data sending task, it will send a FIN segment to start the process of terminating the connection.
[0064] 5) FIN-ACK (Finish Acknowledgment): When the receiving end receives a FIN segment, it will respond with a FIN-ACK segment to confirm the request to close the connection and indicate that it is ready to close the connection itself.
[0065] Reference Figure 1 , this embodiment provides a flow control method based on transmission buffer and processing delay. This method is executed by the sending end and includes the following steps:
[0066] S11. The sending end calculates the first congestion window value according to the size of the sending SRAM buffer. The calculation formula of the first congestion window value is as follows:
[0067]
[0068] where cwnd_size_1 is the first congestion window value; MSS (Maximum Segment Size) is the maximum segment length of the network interface;
[0069] SRAM_send is the size of the sending SRAM buffer; λ s is the environmental impact factor of the sending end, which is used to represent the utilization rate of the sending end. λ s takes values in (0, 1], and a reasonable value can be determined by itself in practice;
[0070] MSS (Maximum segment size) is the maximum segment length. MSS is applied in the TCP protocol and represents the maximum data length that can be transmitted by a single TCP segment.
[0071] In this embodiment, the value of MSS is related to the type of the network interface. The MSS values of common network interfaces are shown in Table 1:
[0072] Table 1
[0073] Network interface type MSS value (unit: byte) Ethernet electrical interface 1460 FDDI 4312 Ethernet optical interface 1Gbps 960 Ethernet optical interface 10Gbps 8910 Ethernet optical interface 40Gbps 33960 Ethernet optical interface 100Gbps 89960
[0074] S12. Send a SYN segment, and the SYN segment includes the first congestion window value; at the same time, record the sending time;
[0075] The first congestion window value is set in the TCP header of the SYN segment; the sending time is used to calculate the RTT;
[0076] S13. Obtain the SYN-ACK segment sent by the receiving end; the SYN-ACK includes a third congestion window value, and the third congestion window value is the smaller value between the second congestion window value calculated by the receiving end according to the size of the receiving SRAM buffer and the first congestion window value;
[0077] The sending end checks whether it has received the SYN-ACK packet sent by the receiving end. If not, it continues to wait. If it has received the SYN-ACK packet, it obtains the SYN-ACK packet sent by the receiving end. The SYN-ACK includes a third congestion window value, which is the smaller value between the second congestion window value calculated by the receiving end according to the size of the receiving SRAM buffer and the first congestion window value.
[0078] S14. Calculate a fourth congestion window value according to the RTT time in the received SYN-ACK packet. The calculation formula for the fourth congestion window value is as follows:
[0079]
[0080] where cwnd_size_4 is the fourth congestion window value, net_rate is the transmission rate of the network; λ is the network environment impact factor, and λ takes values in the range of (0, 1], and a reasonable value can be determined by itself in practice.
[0081] Round-Trip Time (RTT) is an important performance metric in the network, which represents the time required from the sending end sending data to receiving the acknowledgment (SYN-ACK).
[0082] Calculating the RTT based on the time difference between the time of receiving the SYN-ACK packet and the sending time is a prior art and will not be elaborated here.
[0083] S15. Take the smaller value between the third congestion window value and the fourth congestion window value as the fifth congestion window value.
[0084] Pack the fifth congestion window value into the ACK packet and send it to the receiving end. At this time, the fifth congestion window value is used as the congestion window value of the ACK packet.
[0085] The congestion window value in the ACK packet is set in the TCP header of the SYN packet.
[0086] S16. The sending end sends data packets with the fifth congestion window value.
[0087] S17. Enter the data packet sending stage, and the congestion window value is no longer adjusted.
[0088] Specifically, step S17 further includes: during data transmission, when the SRAM buffer is full, the sending stops, and the packet loss is handled by retransmitting the data saved in the SRAM buffer.
[0089] The SRAM buffer is the buffer at the sending end. Its function is to track the data that has been sent. When the buffer is full, it means that the network may have approached or reached its transmission capacity. If data is continued to be sent, more packet losses may occur, thus exacerbating network congestion. Therefore, stopping sending new packets is a preventive measure to reduce network congestion and potential packet losses.
[0090] When an ACK data packet is received from the receiving end, the data will be released from the SRAM buffer, thus pushing the sliding window forward, so as to maintain effective control of network congestion.
[0091] When the SRAM buffer is full, this method will pause sending new packets and handle the packet loss problem by resending the data saved in the SRAM buffer. This is a brute-force method for handling packet losses on a low-latency underlying network, rather than dynamically adjusting the congestion window size like TCP;
[0092] The packet loss judgment adopts a method similar to TCP. After the sender sends a packet, it will start a retransmission timer and wait for the receiver to return an acknowledgment packet (ACK). If the acknowledgment packet has not been received before the timeout retransmission time (RTO) arrives, the sender will consider the packet lost and trigger timeout retransmission.
[0093] This processing method eliminates the need for additional sending credits and reduces the complexity of network switches, ensuring data integrity and transmission reliability.
[0094] Reference Figure 2 , this embodiment also provides a traffic control method based on transmission cache and processing delay. This method is executed by the receiving end and includes the following steps:
[0095] S21. Receive a SYN packet; the SYN packet contains a first congestion window value; the first congestion window value is calculated by the sending end according to the size of the sending SRAM buffer;
[0096] The receiving end starts listening to receive the SYN packet. The SYN packet is a connection establishment packet; the SYN packet contains a first congestion window value;
[0097] S22. The receiving end calculates a second congestion window value according to the size of the receiving SRAM buffer;
[0098] The receiving end checks whether it has received the SYN packet. If not, it continues to wait. If it has received the SYN packet, the receiving end calculates a second congestion window value according to the size of the receiving SRAM buffer and the receiving end environment impact factor. The calculation formula of the second congestion window value is as follows:
[0099]
[0100] Among them, cwnd_size_2 is the second congestion window value; MSS (Maximum Segment Size) is the maximum segment length of the network interface; it should be noted that in this embodiment, the network interface types of the sender and the receiver are the same, so the MSS values of the sender and the receiver are also the same.
[0101] net_rate is the transmission rate of the network; SRAM_recv is the size of the receive SRAM buffer; λ r is the receiver environmental impact factor, which is used to represent the utilization rate of the receiver, λ r takes values in (0, 1], and the reasonable value can be determined by itself in practice.
[0102] S23. Take the smaller value of the first congestion window value and the second congestion window value as the third congestion window value, and send the third congestion window value to the receiver;
[0103] Specifically, pack the third congestion window value into the SYN-ACK message and send it to the sender.
[0104] S24. Receive the ACK message sent by the sender, and use the fifth congestion window value included in the ACK message to receive data messages.
[0105] The receiver checks whether it has received the ACK message sent by the sender. If not, it continues to wait. If it has received it, it uses the fifth congestion window value included in the ACK message to receive data messages;
[0106] To better understand a traffic control method based on transmission buffer and processing delay described in this example, this embodiment provides a specific implementation manner in combination with Embodiment 1 and Embodiment 2, as Figure 3 shown, specifically as follows:
[0107] Suppose net_rate = 100 Gbps = 12.5 GBps, SRAM_send = 1 MB, SRAM_recv = 1 MB, RTT = 30 μs, λ s = 0.3, λ r = 0.25, λ = 0.75.
[0108] MSS is obtained according to the network interface type. Suppose MSS = 1460 Byte;
[0109] The sender calculates the first congestion window value according to its own sending buffer size and the sender environmental impact factor:
[0110]
[0111] The receiving end calculates the second congestion window value based on its own receiving buffer situation and the environmental impact factor of the receiving end, and calculates Since it is smaller than the congestion window of the sending end, that is, smaller than cwnd_size_1, the congestion window cwnd_size_2 = 171 * MSS calculated by the receiving end is selected as the third congestion window value, and the receiving end packs the third congestion window value in the reply SYN-ACK packet;
[0112] The sending end receives the SYN-ACK packet sent by the receiving end, and calculates the fourth congestion window based on RTT = 30 μs Since it is larger than the third congestion window value, the third congestion window is packed as the fifth congestion window value in the ACK packet; At this time, the obtained cwnd_size_2 = 171 * MSS is used as the negotiated congestion window value for the final data sending and receiving, that is, cwnd_size = cwnd_size_2 = 171 * MSS;
[0113] The sending end and the receiving end send and receive data packets according to the negotiated congestion window value cwnd_size.
[0114] In this embodiment, 1 Gbps = 0.125 GBps, 1 M = 1000 KB, 1 KB = 1000 Byte, 1 Byte = 8 bit; When calculating the congestion window value, the relevant parameters of the storage unit are all converted to bit for calculation, and the time-related ones are converted to μs for calculation.
[0115] This embodiment uses the producer (sending end)-consumer (receiving end) model and the M / M / 1 queuing model for simulation testing to deduce the value of the environmental factor of the present invention. The deduction process is as follows:
[0116] (1) Receiving end (consumer):
[0117] The receiving end maintains a buffer to store the received data packets.
[0118] The total number of data blocks received by the receiving end (Blocks Received, BR), the available space of the receiving end (BlocksReceived Limit, BRL). BRL = BR + available buffer space.
[0119] (2) Sending end (producer):
[0120] The sender maintains a counter to record the total number of data blocks sent (Total Blocks Sent, TBS). After receiving an ACK packet, the sender updates the number of data packets it is permitted to send (Block Permitted, BP). The sender will only send a new data packet when TBS + packet size ≤ the latest BP.
[0121] (3) Update and management of BP:
[0122] The update of BP is based on the available space in the receiver buffer. When the receiver finishes processing a data packet, it releases buffer space and notifies the sender to increase the BP value via an ACK.
[0123] (4) Analysis:
[0124] Let the network transmission speed be v n , and the speed of the receiver processing packets be v r . According to queuing theory, the average length of the receiver buffer is It is necessary to satisfy the condition L < SRAM_recv, and v r > v n . Let Then max(λ) = 1. If v r >> v n , λ can theoretically approach infinitesimal. Therefore, it is a reasonable range for λ to take values in (0, 1]. λ s , λ r are the utilization rates of SRAM_send and SRAM_recv respectively, and they can take values in (0, 1]; the present invention does not limit the specific values of λ, λ s , λ r . The reasonable values can be determined by oneself in practice.
[0125] This embodiment provides a flow control method based on transmission cache and processing delay. Instead of using the traditional TCP dynamic congestion window mechanism, it determines the congestion window size based on the SRAM buffer sizes in the client and server hardware when the connection is established, while considering the buffer utilization rates of the receiver and sender. This embodiment reduces the dependence of the transmission protocol on the CPU, has simpler control, higher data throughput rate, reduces packet transmission delay, and thus improves the efficiency and performance of data transmission.
[0126] In addition, when the buffer is full, sending stops, and packet loss is handled by retransmitting the data saved in the SRAM buffer. This method eliminates the need for additional transmission credits and reduces the complexity of the network switch.
[0127] This embodiment provides a traffic control method based on transmission cache and processing delay, which is oriented to high-performance AI computing requirements and named congestion control algorithm Xpress (Express, fast). It controls congestion based on source-side control strategies and local link levels, uses a fixed-size SRAM buffer, and takes into account the buffer utilization rates of both the receiving and sending ends. Instead of TCP's dynamic congestion window, it helps reduce the complexity of congestion management, reduces the dependence of the transmission protocol on the CPU, unifies the congestion control window, helps achieve more consistent performance in low-latency networks, optimizes the low-latency and low-packet-loss environment in supercomputer networks, reduces packet transmission delay, effectively breaks through the bottleneck of existing technologies, and realizes more efficient, more economical, and more reliable data transmission and processing capabilities, laying a solid foundation for continuous innovation in the AI field.
[0128] In addition, the congestion control algorithm of the traffic control method based on transmission cache and processing delay in this embodiment is similar to TCP. It handles congestion by simply discarding packets. Xpress uses fast retransmission and fast recovery to manage network congestion and does not adopt congestion control algorithms such as slow start and congestion avoidance.
[0129] Xpress has a different congestion control mechanism from TCP. It controls congestion by tracking the situation of the SRAM buffer at the sending end. When the SRAM buffer is full, the sending operation will pause until it receives an acknowledgment from the other party and the space in the buffer is released before it will resend. The mechanism of using fast retransmission and fast recovery by Xpress to manage network congestion is as follows:
[0130] 1) Fast retransmission
[0131] Mechanism trigger: When the sending end continuously receives three duplicate acknowledgments (ACKs), it regards these duplicate ACKs as signals of packet loss without waiting for the retransmission timeout (RTO) to occur.
[0132] Immediate retransmission: Once packet loss is detected, the sender will immediately retransmit the lost packet instead of waiting for the retransmission timer to expire.
[0133] 2) Fast recovery
[0134] Enter the normal sending state: After fast retransmission, if the SRAM buffer is full when the sending operation will pause until it receives an acknowledgment from the other party and the space in the buffer is released before it will resend. If the sending SRAM buffer is not full, the sending end enters the normal sending state instead of returning to the slow start state. Different from TCP, the congestion window of xPress is not adjusted during this process.
[0135] The combined use of these two mechanisms can significantly reduce the delay caused by packet loss and improve the efficiency of data transmission.
[0136] The normal change of the TCP congestion window is as Figure 4 shown, and the change of the TCP congestion window using xPress is as Figure 5 shown.
[0137] The final TCP congestion window size (i.e., the fifth congestion window value) for sending packets in this application is calculated through negotiation based on the SRAM buffer sizes in the sender and receiver hardware, and at the same time considering the buffer utilization rates of the receiver and sender. Therefore, the final congestion window size is constant. In Figure 5 it, the change of the congestion window presents a straight line. In this embodiment, the first, second, third, fourth, and fifth congestion windows are intermediate values obtained for calculating the final TCP congestion window. Since they are not shown in the figure, the fifth congestion window value is finally obtained for data packet sending, that is, the fifth congestion window value is the TCP congestion window used when finally sending packets.
[0138] In standard TCP congestion control, the congestion window value is dynamically adjusted according to the network conditions during the data transmission phase. However, in this example, the congestion window is calculated only during the three-way handshake for connection establishment and is not adjusted during the data sending phase. Compared with the conventional TCP congestion control algorithm, the congestion control provided in this embodiment is simpler, has a higher data throughput rate, reduces the packet transmission delay, and thus improves the efficiency and performance of data transmission.
[0139] The parts not detailed in the present invention are prior art. For those skilled in the art, it is obvious that the present invention is not limited to the details of the above exemplary embodiments, and can be implemented in other specific forms without departing from the spirit or basic characteristics of the present invention. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting, aiming to include all changes falling within the meaning and scope of the equivalent elements in the present invention.
Claims
1. A flow control method based on transmission buffer and processing delay, characterized in that: For the sending end, the following steps are included: S11, the sending end calculates the first congestion window value according to the sending SRAM buffer size; S12, sending a SYN message, wherein the SYN message includes a first congestion window value; S13, obtaining a SYN-ACK message sent by the receiving end; the SYN-ACK includes a third congestion window value, and the third congestion window value is a smaller value of the second congestion window value calculated by the receiving end according to the size of the receiving SRAM buffer and the first congestion window value; S14, calculating the fourth congestion window value according to the RTT time in the received SYN-ACK message; S15. Taking the smaller one of the third congestion window value and the fourth congestion window value as the fifth congestion window value; S16. The sending end sends a data message using the fifth congestion window value.
2. The method according to claim 1, characterized in that: The calculation formula of the first congestion window value in step S11 is as follows: Among them, cwnd_size_1 is the first congestion window value; MSS is the maximum segment length of the network interface; SRAM_send is the send SRAM buffer size; λ s is the environmental impact factor at the sending end.
3. The method according to claim 2, characterized in that The calculation formula of the fourth congestion window value in step S14 is as follows: Wherein, cwnd_size_4 is the fourth congestion window value, net_rate is the transmission rate of the network, and λ is the network environment influencing factor.
4. The method according to claim 1, characterized in that: Before step S16, the method further includes: packaging the fifth congestion window value into an ACK message, and sending the ACK message to the receiving end.
5. The method according to claim 1, characterized in that The congestion window value in the SYN-ACK message in step S16 is the congestion window value returned by the receiving end.
6. The method according to claim 1, characterized in that The method further includes: S17, entering the data message sending phase, and the congestion window value is no longer adjusted.
7. A flow control method based on transmission buffer and processing delay, characterized in that: For the receiving end, the following steps are included: S21, receiving a SYN message; the SYN message includes a first congestion window value; the first congestion window value is calculated by the sender according to the size of the sending SRAM buffer; S22, the receiving end calculates a second congestion window value according to the receiving SRAM buffer size; S23, taking the smaller value between the first congestion window value and the second congestion window value as the third congestion window value, and sending the third congestion window value to the receiving end; S24. Receive an ACK message sent by the sender, and use the fifth congestion window value included in the ACK message to receive the data message.
8. The method according to claim 7, characterized in that The calculation formula of the second congestion window value in step S22 is as follows: Among them, cwnd_size_2 is the second congestion window value; MSS is the maximum segment length of the network interface; SRAM_recv is the receiving SRAM buffer size; λ r is the receiving end environment impact factor.
9. The method according to claim 7, characterized in that: The step S23 of sending the third congestion window value to the receiving end specifically includes: packaging the third congestion window value into a SYN-ACK message, and sending it to the sending end.
10. The method according to any one of claims 2, 3 or 8, characterized in that: λ, λ s , r The value is in (0,1].