Transmission control protocol flow control method and apparatus for performing the same

Abstract

A method for controlling transmission control protocol (TCP) flow and an apparatus for performing the method. The method includes sending data packets from a packet processor to a receiver and storing copies of the data packets in an output data buffer, receiving a current acknowledgement packet having a current packet number, determining whether the current packet number is identical to a previous packet number of a previous acknowledgement packet and whether a previous substitute acknowledgement packet having a previous substitute number exists, and performing steps corresponding to different determination results, respectively, to avoid TCP congestion control.

Description

TECHNICAL FIELD

[0001] The present application relates to a Transmission Control Protocol (TCP) flow control method and an apparatus for performing the same. BACKGROUND

[0002] In a wireless network environment such as a 5G wireless communication network, data transmission can be subject to signal loss due to obstruction by objects, high-speed movement, or proximity to a base station, thereby causing packet loss. When packet loss occurs, a packet handler performing data transmission based on a Transmission Control Protocol (TCP) determines that there is congestion in the wireless communication network and thus reduces the transmission rate. The above operation is also referred to as TCP congestion control.

[0003] Five congestion control algorithms are built into the existing Linux kernel, including Reno, Vegas, Westwood, Binary Increase Congestion Control (BIC), and CUBIC, among which CUBIC is mostly used as the default congestion control method. In signal transmission, it is found that about 5% of packet loss can trigger the TCP congestion control method according to the 5G specification. Therefore, the transmission speed will be reduced to less than 30% of the original, while the bandwidth still retains about 95% of the ideal state, which can be known from the user datagram protocol (UDP). However, a packet handler performing data transmission based on UDP cannot verify the correctness of the data. Therefore, a control mechanism is needed to prevent the TCP-based packet handler from entering the congestion control state, thereby ensuring the transmission speed. SUMMARY

[0004] According to an embodiment of the present application, a Transmission Control Protocol (TCP) flow control method is provided. The method comprises: sending a data packet from a packet processor to a receiver and storing a copy of the data packet to an output data buffer; receiving a current acknowledgement packet with a current packet number after the data packet is sent with an input acknowledgement filter; determining, with the input acknowledgement filter, whether the current packet number is consistent with a previous packet number of a previous acknowledgement packet and whether a previous replacement acknowledgement packet with a previous replacement number exists; sending the current acknowledgement packet to the packet processor with the input acknowledgement filter when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet does not exist; determining, with the input acknowledgement filter, whether the current packet number is greater than or equal to the previous replacement number when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet exists; sending the current acknowledgement packet to the packet processor with the input acknowledgement filter when the current packet number is determined to be greater than or equal to the previous replacement number; and re-sending the data packet to the receiver, generating a current replacement acknowledgement packet and selectively sending the current replacement acknowledgement packet to the packet processor when the current packet number is consistent with the previous packet number or when the current packet number is determined to be less than the previous replacement number.

[0005] According to another embodiment of the present application, a TCP flow control device is provided. The device comprises: an output data buffer, which is communicatively coupled between a packet processor and a receiver, wherein the output data buffer stores a copy of a data packet sent from the packet processor to the receiver, and the output data buffer re-sends the data packet to the receiver upon receiving a re-sending instruction based on the copy; and an input acknowledgement filter, which is communicatively coupled to the output data buffer and communicatively coupled between the packet processor and the receiver, wherein the input acknowledgement filter receives a current acknowledgement packet having a current packet number, and the input acknowledgement filter determines whether the current packet number is identical to a previous packet number of a previous acknowledgement packet and whether a previous replacement acknowledgement packet having a previous replacement number exists; wherein, when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet does not exist, the input acknowledgement filter sends the current acknowledgement packet to the packet processor; when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet exists, the input acknowledgement filter determines whether the current packet number is greater than or equal to the previous replacement number; when the current packet number is determined to be greater than or equal to the previous replacement number, the input acknowledgement filter sends the current acknowledgement packet to the packet processor; when the current packet number is identical to the previous packet number or when the current packet number is determined to be less than the previous replacement number, the output data buffer re-sends the data packet to the receiver, and the input acknowledgement filter generates a current replacement acknowledgement packet and selectively sends the current replacement acknowledgement packet to the packet processor.

[0006] In summary, the present application provides a TCP flow control method and a TCP flow control device, which can be used as a TCP flow control mechanism to avoid TCP data transmission from entering a congestion control state, to ensure an optimal transmission speed, and is superior to other TCP congestion control algorithms.

[0007] The above description and the following description of embodiments of the present disclosure are intended to demonstrate and explain the spirit and principle of the present application, and to provide further explanation of the claims of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0008] Figure 1A is a diagram illustrating data transmission by a Transmission Control Protocol (TCP) in a normal state.

[0009] Figure 1B is a graph of the sequence number of acknowledgement (ACK) packets returned for TCP data transmission in a normal state (0% packet loss rate).

[0010] Figure 2Ais a graph illustrating a condition where packet loss occurs in data transmission through TCP.

[0011] Figure 2B is a graph illustrating the sequence numbers of the acknowledgement packets returned when the TCP transmission has a 5% packet loss rate.

[0012] Figure 3 is a block diagram illustrating the structure of a TCP flow control device according to an embodiment of the present disclosure.

[0013] Figure 4 is a flowchart illustrating an embodiment of a TCP flow control method that can be executed by the TCP flow control device shown in Figure 3

[0014] Figure 5 is a flowchart illustrating an embodiment of the details of step S8 shown in Figure 4

[0015] Figure 6 is a flowchart illustrating an embodiment of the details of step S86 shown in Figure 5

[0016]

Symbol Explanation

[0017] Sd: Sender

[0018] Rc: Receiver

[0019] DP1, DP2, DP3, DP4: Data packet

[0020] AP1, AP2, AP3, AP1', AP1": Acknowledgement packet

[0021] 1: TCP flow control device

[0022] 2: Packet processor

[0023] 11: Output data buffer

[0024] 12: Input acknowledgement filter

[0025] S1-S8, S81-S86, S861-S864: Step DETAILED DESCRIPTION

[0026] The detailed features and advantages of the present application are described in detail in the embodiments below, which are sufficient to enable those skilled in the art to understand the technical content of the present application and to implement it, and those skilled in the art can easily understand the related purposes and advantages of the present application according to the content disclosed in the specification, claims and drawings. The following embodiments further illustrate the ideas of the present application, but do not limit the scope of the present application in any way. ​​​

[0027] Referring to Figure 1A and Figure 1B wherein Figure 1A is a plot illustrating data transmission by Transmission Control Protocol (TCP) in a normal state, and Figure 1B shows a plot of the sequence numbers of the acknowledgement (ACK) packets returned when TCP data transmission is normal, i.e. with a packet loss rate of 0%. As Figure 1A illustrated, when data transmission by TCP is functioning in a normal state, data packets are sequentially sent from a sender Sd to a receiver Rc, and the receiver Rc returns acknowledgement packets in response to the data packets. For example, as Figure 1A illustrated, a data packet DP1 is first sent by the sender Sd, and the receiver Rc returns an acknowledgement packet AP1 to the sender Sd with a sequence number associated with the data packet DP1 showing an expected number contiguous to the end number of the data packet DP1 to indicate safe receipt of the data packet DP1. Regardless of whether the acknowledgement packet AP1 is received at the sender Sd, the sender Sd further sends a data packet DP2 to the receiver Rc, and the receiver Rc sends an acknowledgement packet AP2 upon receipt of the data packet DP2. The data transmission proceeds in this manner until there are no more packets in the TCP stack and no packet loss, i.e. as Figure 1A illustrated, all the data packets DP1, DP2 and DP3 have been safely received by the receiver Rc and all the acknowledgement packets AP1, AP2 and AP3 have been safely received by the sender Sd. Figure 1B illustrated, the receiver Rc continuously returns acknowledgement packets of different and increasing sequence numbers to the sender Sd due to the absence of congestion in the data transmission.

[0028] On the contrary, the state of data transmission with packet loss is illustrated in Figure 2A and Figure 2B wherein Figure 2A is a plot illustrating the occurrence of packet loss condition, and Figure 2B shows a plot illustrating the sequence numbers of the acknowledgement packets returned when TCP transmission has a packet loss rate of 5%. As Figure 2AIn the example shown in FIG. 1, after receiving the acknowledgement packet AP1, the sender Sd sends the data packet DP2 to the receiver Rc, but a packet loss occurs and thus the receiver Rc does not receive the data packet DP2 or is not aware of the existence of the data packet DP2. Thereafter, once the receiver Rc receives the data packet DP3 from the sender Sd, the receiver Rc finds that the data packet DP2 is lost and thus sends an acknowledgement packet AP1' back to the sender Sd. The acknowledgement packet AP1' still has the packet number associated with the data packet DP1 to inform the sender Sd that the data packet DP2 is lost and can be re-sent. In TCP-based data transmission, the acknowledgement packet AP1' not only includes the packet number associated with the data packet DP1, but also includes selective acknowledgement (SACK) data, which shows the information of one or more data packets received by the receiver Rc after it judges that the data packet DP2 is lost. In this case, the SACK data of the acknowledgement packet AP1' is "2130-3589", which shows the start number and the end number of the data packet DP3, which is the packet received by the receiver Rc after the packet loss of the data packet DP2 occurs. However, the SACK data of the acknowledgement packet AP1" is "2130-5049", which shows the start number of the data packet DP3 and the end number of the data packet DP4. Figure 2A In the example shown in FIG. 1, after receiving the acknowledgement packet AP1, the sender Sd sends the data packet DP2 to the receiver Rc, but a packet loss occurs and thus the receiver Rc does not receive the data packet DP2 or is not aware of the existence of the data packet DP2. Thereafter, once the receiver Rc receives the data packet DP3 from the sender Sd, the receiver Rc finds that the data packet DP2 is lost and thus sends an acknowledgement packet AP1' back to the sender Sd. The acknowledgement packet AP1' still has the packet number associated with the data packet DP1 to inform the sender Sd that the data packet DP2 is lost and can be re-sent. In TCP-based data transmission, the acknowledgement packet AP1' not only includes the packet number associated with the data packet DP1, but also includes selective acknowledgement (SACK) data, which shows the information of one or more data packets received by the receiver Rc after it judges that the data packet DP2 is lost. In this case, the SACK data of the acknowledgement packet AP1' is "2130-3589", which shows the start number and the end number of the data packet DP3, which is the packet received by the receiver Rc after the packet loss of the data packet DP2 occurs. However, the SACK data of the acknowledgement packet AP1" is "2130-5049", which shows the start number of the data packet DP3 and the end number of the data packet DP4. Figure 2B As shown, due to the 5% packet loss rate, the curve of the data transmission is divided into several line segments, and the receiver Rc frequently sends the acknowledgement packets with the same sequence number back to the sender Sd.

[0029] Please refer to Figure 3 , which is a block diagram of the structure of a TCP flow control device according to an embodiment of the present disclosure, which is applied to a network of a 5G architecture. In this embodiment, the TCP flow control device 1 is adapted to a sender Sd and is communicatively connected between a packet processor 2 of the sender Sd and a receiver Rc. As shown in FIG. 2, the TCP flow control device 1 includes a packet loss detection module 10, a packet loss recovery module 20, and a packet loss recovery module 30. Figure 3As shown, the TCP flow control device 1 comprises an output data buffer 11 and an input acknowledgement filter 12, wherein the output data buffer 11 is communicatively connected between the packet processor 2 and the receiver Rc, and the input acknowledgement filter 12 is communicatively connected to the output data buffer 11 and between the packet processor 2 and the receiver Rc. In this embodiment, the communication between the output data buffer 11 and the input acknowledgement filter 12 can be performed by direct interconnection. Alternatively, however, these two elements of the TCP flow control device 1 can be communicatively connected through the packet processor 2 instead of direct interconnection.

[0030] Reference is made to Figure 3 and Figure 4 wherein Figure 4 An embodiment of the TCP flow control method is shown in the flowchart of Fig. 1. In this embodiment, the TCP flow control method of the present disclosure can comprise the steps S1 to S8 as shown. Further, the TCP flow control method first judges whether the current packet number of a current acknowledgement packet is identical to a previous packet number, and judges whether a previous substitute acknowledgement packet generated by the input acknowledgement filter 12 exists, and then performs steps corresponding to different judging results, respectively. The previous packet number and the previous substitute acknowledgement packet will be explained in detail hereinafter. Figure 3

[0031] In step S1, the sender Sd sends a data packet from the packet processor 2 to the receiver Rc through the network, and the sender Sd also stores a copy of the data packet into the output data buffer 11. Although Figure 3 It is shown in Fig. 1 that the packet processor 2 sends the data packet out through the output data buffer 11, alternatively, the packet processor 2 sends the data packet out independently without passing through the output data buffer 11 and storing a copy into the output data buffer 11.

[0032] In step S2, after the data packet mentioned in step S1 is sent, the input acknowledgement filter 12 receives a current acknowledgement packet with a current packet number. Depending on the condition of data transmission, if the data transmission is performed without packet loss condition, this current acknowledgement packet can be an acknowledgement packet like the acknowledgement packet AP1 as shown in Figure 1A and 2A or if packet loss condition occurs, like the acknowledgement packet AP1' or AP1" as shown in Figure 2A .

[0033] In step S3, the input acknowledgement filter 12 judges whether the current packet number of the current acknowledgement packet is identical to a previous packet number. The previous packet number can be the packet number of a previous acknowledgement packet received before the current acknowledgement packet, to judge whether the copy of the data packet in the output data buffer 11 can be deleted.​

[0034] In step S4, the copy of the data packet in the output data buffer 11 can be deleted when the current packet number is different from the previous packet number. Step S4 is an optional step, and step S4 can be skipped if the available storage space in the output data buffer 11 is still sufficient. The input acknowledgement filter 12 can generate a deletion instruction, and send the deletion instruction to the output data buffer 11 directly or through the packet processor 2, so that the output data buffer 11 can delete the copy of the data packet accordingly.

[0035] Subsequent to step S4 or step S3 (if step S4 is skipped), in step S5, the input acknowledgement filter 12 further determines whether there is a previous replacement acknowledgement packet when the current packet number is different from the previous packet number. The previous replacement acknowledgement packet is an acknowledgement packet selectively generated by the input acknowledgement filter 12 after the previous acknowledgement packet is received, wherein the previous replacement acknowledgement packet has a packet number referred to as "previous replacement number" hereinafter, and details of which will be described hereinafter. With this step S5, even if the current packet number is different from the previous packet number, the input acknowledgement filter 12 can determine whether sending the current acknowledgement packet back to the packet processor 2 can trigger the TCP congestion control.

[0036] In step S6, when it is determined in step S5 that there is no previous replacement acknowledgement packet, the input acknowledgement filter 12 sends the current acknowledgement packet to the packet processor 2, such as the acknowledgement packet AP1 or AP2 as shown in FIG. 1, and does not cause the packet processor 2 to initiate the TCP congestion control. On the contrary, in step S7, when it is determined in step S5 that there is a previous replacement acknowledgement packet, the input acknowledgement filter 12 further determines whether the current packet number is greater than or equal to the previous replacement number. When the determination result of step S7 is "Yes", i.e., the current packet number is greater than or equal to the previous replacement number, step S6 is then executed. However, when the determination result of step S7 is "No", step S8 introduced hereinafter will then be executed. Figure 1A

[0037] ​In step S8, when it is determined in step S3 that the current packet number is identical to the previous packet number, or when it is determined in step S7 that the current packet number is smaller than the previous replacement number, the input acknowledgement filter 12 generates a current replacement acknowledgement packet, selectively sends the current replacement acknowledgement packet to the packet processor 2, and causes the data packet to be retransmitted to the receiver Rc based on the copy in the output data buffer 11. In the above step S8, the input acknowledgement filter 12 can send a current replacement acknowledgement packet instead of a current acknowledgement packet to the packet processor 2, wherein the packet number of the current replacement acknowledgement packet (hereinafter referred to as "current replacement number") is at least greater than the current packet number, so as to avoid the TCP congestion control from being triggered. In addition, in this embodiment, the input acknowledgement filter 12 can generate a retransmission instruction, and send the retransmission instruction to the output data buffer 11, so as to instruct the output data buffer 11 to retransmit the missing data packet.

[0038] Reference is made to Figure 5 , Figure 5 Details of step S8 are shown, which includes steps S81 to S86. In this embodiment, in steps S81 to S86, the input acknowledgement filter 12 can set the current replacement number to different values depending on different conditions, so as to avoid the TCP congestion control in the case that the current replacement acknowledgement packet with the current replacement number is sent to the packet processor 2. Step S86 can include a mechanism for determining whether the input acknowledgement filter 12 sends the generated current replacement acknowledgement packet to the packet processor 2 instead of sending a current acknowledgement packet, details of which are described later.

[0039] In step S81, when the current packet number is determined to be smaller than the previous replacement number in step S7, the input acknowledgement filter 12 sets the sum of the difference between the current packet number and the previous packet number and the previous replacement number as the current replacement number. Since it is determined in step S5 that the previous replacement acknowledgement packet exists and the current packet number is smaller than the previous replacement number, the input acknowledgement filter 12 sets the current replacement number to be greater than the previous replacement number, or the TCP congestion control can be triggered. Although the difference between the current packet number and the previous packet number is applied as an increment from the previous replacement number to the current replacement number in this embodiment, the increment is not limited thereto.

[0040] In step S82, when it is judged in step S3 that the current packet number is identical to the previous packet number, the input acknowledgement filter 12 further judges whether or not the previous replacement acknowledgement packet exists. Since the current packet number is identical to the previous packet number, if the current acknowledgement packet is sent to the packet processor 2, this current packet number can trigger TCP congestion control. In order to set the current replacement number to effectively avoid triggering TCP congestion control, the input acknowledgement filter 12 further performs this step S82. The existence of the previous replacement acknowledgement packet indicates that sending an acknowledgement packet with a packet number less than or equal to the previous replacement number can cause TCP congestion control. Therefore, after this step S82, the input acknowledgement filter 12 can set the current replacement number corresponding to the judging result of this step S82.

[0041] In step S83, when the previous replacement acknowledgement packet is not recognized in step S82, the input acknowledgement filter 12 sets the current replacement number as the maximum value of the SACK data of the current acknowledgement packet. That is, in this embodiment, the current acknowledgement packet can be similar to the acknowledgement packet API' in Figure 2A , in which the SACK data is first shown in the acknowledgement packet with the current packet number.

[0042] In step S84, when the judging result of step S82 is that the previous replacement acknowledgement packet exists, the input acknowledgement filter 12 further judges whether or not the maximum value of the SACK data of the current acknowledgement packet is equal to the previous replacement number. When the packet numbers of the current and previous acknowledgement packets are identical, the maximum value of the SACK data of the current acknowledgement packet can be greater than the maximum value of the SACK data of the previous acknowledgement packet. Therefore, in the case that the maximum value of the SACK data of the current acknowledgement packet is different from the previous replacement number, the maximum value of the SACK data of the current acknowledgement packet can not yet be used as the value of the packet number of the replacement acknowledgement packet, and thus step S83 occurs to set the maximum value of the SACK data of this current acknowledgement packet as the current replacement number. On the contrary, in the case that the maximum value of the SACK data of the current acknowledgement packet is equal to the previous replacement number, the input acknowledgement filter 12 performs the following step S85 to avoid sending the replacement acknowledgement packet with the packet number identical to the previous replacement number, which can cause triggering of TCP congestion control.

[0043] In step S85, since the maximum value of the SACK data of the current acknowledgement packet has been used as the packet number of the replacement acknowledgement packet, the input acknowledgement filter 12 sets a predetermined value and the previous replacement number of the previous replacement acknowledgement packet as the current replacement number to avoid TCP congestion control. The predetermined value can be the minimum data length that the packet processor 2 can receive, such as 1448.

[0044] Finally, after step S81, step S83 or step S85, step S86 is performed to enable the input acknowledgement filter 12 to selectively send the current replacement acknowledgement packet to the packet processor 2 based on the copy in the output data buffer 11 and to cause the data packet to be retransmitted to the receiver Rc.

[0045] Referring to Figure 6 Fig. 8 shows details of step S86, which is concerned with determining whether there is a packet loss condition to avoid the situation where the input acknowledgement filter 12 has sent multiple replacement acknowledgement packets, which is suitable for TCP congestion control in data transmission. Step S86 can include sub-steps S861 to S864 to perform TCP congestion control. In sub-step S861, the input acknowledgement filter 12 determines whether the difference between the current replacement number of the current replacement acknowledgement packet and the current packet number falls within an operational range, for example, is equal to or less than a predetermined value. In one embodiment, the input acknowledgement filter 12 can subtract the current packet number from the current replacement number and check whether the result of the calculation is lower than the predetermined value. In sub-step S862, when the difference falls within the operational range, it indicates that the packet processor 2 can continue to send data packets normally, and the input acknowledgement filter 12 sends the current replacement acknowledgement packet to the packet processor 2. Conversely, in sub-step S863, when the difference falls outside the operational range, it indicates that it is time to initiate TCP congestion control, and the input acknowledgement filter 12 sends the current acknowledgement packet to the packet processor 2. Finally, in sub-step S864, the input acknowledgement filter 12 causes the data packet to be retransmitted to the receiver Rc based on the copy in the output data buffer 11. Although sub-step S864 is shown as being performed after sub-step S862 or sub-step S863, sub-step S864 can be performed before sub-step S861 or simultaneously with sub-step S861, sub-step S862 or sub-step S863. In this way, if the condition of packet loss becomes more serious, the packet processor 2 can initiate TCP congestion control in time.

[0046] In the above manner, since the packet processor 2 receives an acknowledgement packet instead of the current acknowledgement packet when the current acknowledgement packet is determined to be not greater than the packet number of the last acknowledgement packet sent to the packet processor 2, whether the last acknowledgement packet is a previous acknowledgement packet or a previous replacement acknowledgement packet, the sender Sd does not easily initiate TCP congestion control.

[0047] Table 1 below shows a comparison of the present application with various TCP congestion control algorithms in terms of packet loss rate, where the length of transmission time of the packets is the same. As shown in Table 1, the comparison results between the present application and various TCP congestion control methods (indicated by the X axis) under different packet loss rates (indicated by the Y axis) are as follows.

[0048] Table 1 (The unit of the values corresponding to each congestion control method in Table 1 is Mbits / sec)

[0049]

[0050] At a packet loss rate of 0%, the transmission speed of the TCP flow control method of the present application and all TCP congestion control methods can be 942 Mbits / sec in a fixed period. At a packet loss rate of 1%, the transmission speed of the TCP flow control method can be 820 Mbits / sec, while the transmission speed of the CUBIC TCP congestion control method is 710 Mbits / sec, the transmission speed of the Reno TCP congestion control method is 657 Mbits / sec, the transmission speed of the Vegas TCP congestion control method is 423 Mbits / sec, the transmission speed of the Westwood TCP congestion control method is 373 Mbits / sec, and the transmission speed of the BIC TCP congestion control method is 329 Mbits / sec.

[0051] At a packet loss rate of 5%, the transmission speed of the TCP flow control method is 763 Mbits / sec, while the transmission speed of the CUBIC TCP congestion control method is 201 Mbits / sec, the transmission speed of the Reno TCP congestion control method is 66 Mbits / sec, the transmission speed of the Vegas TCP congestion control method is 34 Mbits / sec, the transmission speed of the Westwood TCP congestion control method is 57 Mbits / sec, and the transmission speed of the BIC TCP congestion control method is 24 Mbits / sec in a fixed period.

[0052] At a packet loss rate of 10%, the transmission speed of the TCP flow control method is 521 Mbits / sec, while the transmission speed of the CUBIC TCP congestion control method is 6 Mbits / sec, the transmission speed of the Reno TCP congestion control method is 8 Mbits / sec, the transmission speed of the Vegas TCP congestion control method is 4 Mbits / sec, the transmission speed of the Westwood TCP congestion control method is 7 Mbits / sec, and the transmission speed of the BIC TCP congestion control method is 4 Mbits / sec in a fixed period.

[0053] Please refer to Table 2, which shows the packet loss rate and the corresponding transmission rate of the TCP flow control method to the CUBIC algorithm. As shown in Table 2, at different packet loss rates (indicated by the Y axis), the comparison results between the TCP flow control method and the TCP CUBIC congestion control method (indicated by the X axis) are as follows.

[0054] Table 2

[0055] Packet loss rate TCP flow control method CUBIC 0％ 12.64 seconds (897 Mbits / sec) 12.64 seconds (897 Mbits / sec) 1％ 15.55 seconds (729 Mbits / sec) 19.74 seconds (585 Mbits / sec) 5％ 17.42 seconds (661 Mbits / sec) 42.51 seconds (268 Mbits / sec) 10％ 29.86 seconds (381 Mbits / sec) 596.75 seconds (19 Mbits / sec)

[0056] At 0% packet loss, both TCP flow control method and CUBIC TCP congestion control method took 12.64 seconds (i.e. 897 Mbits / sec) to transmit a fixed number of packets.

[0057] At 1% packet loss, TCP flow control method took 15.55 seconds (i.e. 729 Mbits / sec) to transmit a fixed number of packets, while CUBIC TCP congestion control method took 19.74 seconds (i.e. 585 Mbits / sec) to complete the same task.

[0058] At 5% packet loss, TCP flow control method took only 17.42 seconds (i.e. 661 Mbits / sec) to transmit a fixed number of packets, while CUBIC TCP congestion control method took 42.51 seconds (i.e. 268 Mbits / sec) to complete the same task.

[0059] At 10% packet loss, TCP flow control method took only 29.86 seconds (i.e. 381 Mbits / sec) to transmit a fixed number of packets, while CUBIC TCP congestion control method took 596.7 seconds (i.e. 19 Mbits / sec) to complete the same task.

[0060] As shown in Tables 1 and 2, TCP flow control method can fix the problem of improper speed limitation mechanism of 5G wireless communication system, thereby greatly improving user experience while still triggering TCP congestion control when it is really needed.

[0061] In summary, the present application provides a TCP flow control method and a TCP flow control device, which can be used as TCP flow control mechanism to avoid TCP data transmission from entering congestion control state, thereby ensuring optimal transmission speed and being superior to other TCP congestion control algorithms.

Claims

1. A method for TCP flow control, comprising: sending a data packet from a packet processor to a receiver and storing a copy of the data packet to an output data buffer; receiving a current acknowledgement packet with a current packet number at an input acknowledgement filter after the data packet is sent; determining, at the input acknowledgement filter, whether the current packet number is identical to a previous packet number of a previous acknowledgement packet and whether a previous replacement acknowledgement packet with a previous replacement number exists; sending, at the input acknowledgement filter, the current acknowledgement packet to the packet processor when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet does not exist; determining, at the input acknowledgement filter, whether the current packet number is greater than or equal to the previous replacement number when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet exists; sending, at the input acknowledgement filter, the current acknowledgement packet to the packet processor when the current packet number is determined to be greater than or equal to the previous replacement number; and re-sending the data packet to the receiver, generating a current replacement acknowledgement packet and selectively sending the current replacement acknowledgement packet to the packet processor when the current packet number is identical to the previous packet number or when the current packet number is determined to be less than the previous replacement number, wherein selectively sending the current replacement acknowledgement packet to the packet processor comprises: determining whether a difference between a current replacement number and the current packet number falls within an operating range; sending the current replacement acknowledgement packet to the packet processor when the difference falls within the operating range; and sending the current acknowledgement packet to the packet processor when the difference falls outside the operating range.

2. The method for TCP flow control of claim 1, wherein generating the current replacement acknowledgement packet comprises: setting, at the input acknowledgement filter, the current replacement number as a sum of a difference between the current packet number and the previous packet number and the previous replacement number when the current packet number is determined to be less than the previous replacement number, wherein the current replacement number is a packet number of the current replacement acknowledgement packet; determining, at the input acknowledgement filter, whether a maximum value of selective acknowledgement data of the current acknowledgement packet is equal to the previous replacement number when the current packet number is identical to the previous packet number and the previous replacement acknowledgement packet exists; setting, at the input acknowledgement filter, the maximum value of the selective acknowledgement data of the current acknowledgement packet as the current replacement number when the maximum value of the selective acknowledgement data of the current acknowledgement packet is different from the previous replacement number or when the current packet number is determined to be identical to the previous packet number and the previous replacement acknowledgement packet does not exist; and setting, at the input acknowledgement filter, the current replacement number as a sum of a preset value and the previous replacement number when the maximum value of the selective acknowledgement data of the current acknowledgement packet is equal to the previous replacement number.

3. The method for TCP flow control of claim 1, further comprising deleting the copy of the data packet in the output data buffer when the current packet number is different from the previous packet number. ​ ​ ​ 4. The TCP flow control method of claim 3, wherein deleting the copy of the data packet in the output data buffer comprises: sending a delete instruction to the output data buffer with the input acknowledgement filter; and deleting the copy of the data packet in the output data buffer according to the received delete instruction.

5. The TCP flow control method of claim 1, wherein retransmitting the data packet to the receiver comprises: sending a retransmit instruction to the output data buffer with the input acknowledgement filter; and retransmitting the data packet with the output data buffer according to the copy upon receiving the retransmit instruction with the output data buffer.

6. A TCP flow control apparatus comprising: an output data buffer for communicatively coupling between the packet processor and the receiver, wherein the output data buffer stores a copy of a data packet transmitted from the packet processor to the receiver, and based on the copy, the output data buffer retransmits the data packet to the receiver upon receiving a retransmission instruction; an output data buffer for storing data packets to be transmitted to a receiver; and an input acknowledgement filter communicatively coupled to the output data buffer and communicatively coupled between a packet processor and the receiver, wherein the input acknowledgement filter receives a current acknowledgement packet having a current packet number, and the input acknowledgement filter determines whether the current packet number is identical to a previous packet number of a previous acknowledgement packet and whether a previous replacement acknowledgement packet having a previous replacement number exists; wherein, when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet does not exist, the input acknowledgement filter sends the current acknowledgement packet to the packet processor; when the current packet number is different from the previous packet number and the previous replacement acknowledgement packet exists, the input acknowledgement filter determines whether the current packet number is greater than or equal to the previous replacement number; when the current packet number is determined to be greater than or equal to the previous replacement number, the input acknowledgement filter sends the current acknowledgement packet to the packet processor; when the current packet number is identical to the previous packet number or when the current packet number is determined to be less than the previous replacement number, the output data buffer retransmits the data packet to the receiver, and the input acknowledgement filter generates a current replacement acknowledgement packet and selectively sends the current replacement acknowledgement packet to the packet processor, wherein, to selectively send the current replacement acknowledgement packet to the packet processor, the input acknowledgement filter determines whether a difference between a current replacement number and the current packet number falls within an operation range, sends the current replacement acknowledgement packet to the packet processor when the difference falls within the operation range, and sends the current acknowledgement packet to the packet processor when the difference falls outside the operation range.

7. The transmission control protocol flow control apparatus of claim 6 wherein, To generate the current alternative acknowledgement packet, when the current packet number is judged to be less than the previous alternative number, the input acknowledgement filter sets the current alternative number as the sum of the difference between the current packet number and the previous packet number and the previous alternative number, judges whether the maximum value of the selective acknowledgement data of the current acknowledgement packet is equal to the previous alternative number when the current packet number is identical to the previous packet number and the previous alternative acknowledgement packet exists, sets the maximum value of the selective acknowledgement data of the current acknowledgement packet as the current alternative number when the maximum value of the selective acknowledgement data of the current acknowledgement packet is different from the previous alternative number or when the current packet number is identical to the previous packet number and no previous alternative acknowledgement packet exists, and sets the maximum value of the selective acknowledgement data of the current acknowledgement packet as the current alternative number when the maximum value of the selective acknowledgement data of the current acknowledgement packet is equal to the previous alternative number.

8. The transmission control protocol flow control device of claim 6, wherein the output data buffer deletes the copy when receiving a deletion instruction from the input acknowledgement filter, and the input acknowledgement filter generates the deletion instruction when the current packet number is different from the previous packet number.

Images