A method and system for wide area network TCP congestion control based on early packet loss feedback

Abstract

The application discloses a kind of WAN TCP congestion control method and system based on early packet loss feedback, method includes: establishing a TCP connection between sending end and receiving end, sending end sends TCP data message to receiving end;TCP data message is received at transit device, and forwarding is carried out, if the exit queue buffer reaches the discard threshold when forwarding, then mark the message loss of TCP stream in the corresponding direction, discard TCP data message and generate RDN notification message;Transit device sends RDN notification message to sending end, and sending end receives and marks the loss of corresponding data message, enters congestion control state;Sending end retransmits the data message carrying CWR flag, and transit device receives that sending end has responded RDN loop, and clears the congestion flag bit of corresponding TCP stream.The application designs shorter early packet loss feedback control loop, can significantly reduce control delay, so that sending end more timely perceives congestion and reacts, reduces the occurrence of subsequent packet loss, accurately assists sending end to retransmit lost data section.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of TCP congestion control, and particularly relates to a wide area network TCP congestion control method and system based on early packet loss feedback. BACKGROUND

[0002] With the rapid development of communication technology and the increasing demand for high-speed transmission of human beings, the bandwidth of wide area network links increases year by year. At the same time, how to effectively control the congestion of high-bandwidth wide area network has become increasingly attractive. The traffic composition in the wide area network is complex, which not only contains delay-sensitive short flows (such as live broadcast, voice, etc.), but also contains long flows sensitive to flow completion time (such as file transmission, financial business, etc.). When these two types of traffic encounter congestion caused by packet loss, they will be affected to different degrees: short flows need to retransmit data, resulting in at least doubled delay; long flows will lose a segment of data and enter congestion control for speed reduction, and will exit the congestion control state only after retransmitting the lost data, resulting in an increase in flow completion time. In the long-distance wide area network scenario, due to the large round-trip delay, the congestion feedback is lagging, and in this case, for short flow packet loss, the delay caused by retransmission will greatly degrade the performance, and for long flow packet loss, because a considerable amount of data will be lost and there is no accurate retransmission sequence number guide, the sender needs a long time to exit the congestion control, resulting in bandwidth loss. Due to the limitations of chip area and the high cost of SRAM, the buffer of the commercial switch in the wide area network cannot match the bandwidth it supports well, which means that congestion packet loss is quite common in the wide area network.

[0003] The existing wide area network TCP congestion control algorithm mainly collects network congestion signals to let the sender execute accordingly. These congestion signals can be packet loss, delay, and bandwidth, but they all have a problem: when congestion occurs, the data packet carrying the information needs to first arrive at the receiver and then return to the sender through ACK to be responded. This requires at least 1 RTT from the occurrence of congestion, which cannot well solve the congestion control in the long round-trip delay wide area network scenario. In order to optimize the congestion control in the wide area network scenario, it seems possible to redesign the congestion control algorithm, but considering that the TCP congestion control system has developed for decades, it is very difficult to completely independently design a new control system and consider the fairness problem of coexistence with traditional TCP traffic. Retaining the original congestion control algorithm to a certain extent and shortening the congestion control loop and reducing the congestion feedback delay is a feasible and effective solution. SUMMARY

[0004] This section is intended to summarize some aspects of the embodiments of the present application and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section as well as in the summary of the application and the title of the application in order to avoid obscuring the purpose of this section, the summary of the application and the title of the application, and such simplifications or omissions are not to be construed as limiting the scope of the present application.

[0005] In view of the above-mentioned existing problems, the present application is proposed. Therefore, the present application provides a wide area network TCP congestion control method based on early packet loss feedback to solve the problem of congestion control in a wide area network scene with long round-trip delay.

[0006] To solve the above technical problems, the present application provides the following technical solutions:

[0007] In a first aspect, the present application provides a wide area network TCP congestion control method based on early packet loss feedback, comprising: establishing a TCP connection between a sending end and a receiving end, the sending end sending a TCP data packet to the receiving end;

[0008] The transit device receives the TCP data packet and forwards it, and if the egress queue buffer reaches the discard threshold during forwarding, marks that there is packet loss in the corresponding direction TCP flow, discards the TCP data packet and generates an RDN notification packet;

[0009] The transit device sends the RDN notification packet to the sending end, and the sending end receives and marks the corresponding data packet loss, and enters a congestion control state;

[0010] The sending end retransmits the data packet carrying the CWR flag, and the transit device receives that the sending end has responded to the RDN loop and clears the corresponding TCP flow congestion flag bit.

[0011] As a preferred scheme of the wide area network TCP congestion control method based on early packet loss feedback, wherein: generating an RDN notification packet comprises:

[0012] The RDN notification packet includes a DROP_NOTIFY packet and a CWR_REQ packet;

[0013] When the transit device receives a data packet, if there is no buffer capacity to forward the data packet, the data packet that should be discarded is generated as a DROP_NOTIFY packet through field editing, including:

[0014] Discard the TCP payload and TCP option of the data packet, only keep the transport layer and previous headers;

[0015] Exchange the four-tuple of the data packet, including the destination IP address, the source IP address, the destination port number and the source port number;

[0016] Recalculating IP header, TCP header checksum;

[0017] Re-routing the data packet and putting it into the high priority queue of the out port for priority forwarding.

[0018] As a preferred scheme of the wide area network TCP congestion control method based on early packet loss feedback provided by the present application, wherein the CWR_REQ packet comprises:

[0019] Designing a congestion marking hash table at the transit device, when packet loss occurs at the transit device and a DROP_NOTIFY packet is generated, setting the congestion hash table value corresponding to the TCP flow to 1;

[0020] Based on the ACK returned by the receiving end, the transit device receives a TCP ACK packet;

[0021] Reading the congestion hash table key value of the reverse direction TCP flow corresponding to the TCP ACK packet, i.e. the value of the four-tuple;

[0022] If the value is 1, the TCP ACK packet carries CWR_REQ information, the CWR_REQ packet is generated, and is forwarded to the sending end.

[0023] As a preferred scheme of the wide area network TCP congestion control method based on early packet loss feedback provided by the present application, wherein the sending end receives and marks the corresponding data packet loss, and enters the congestion control state, comprising:

[0024] The sending end responds to the DROP_NOTIFY and CWR_REQ packets arriving from the transit device;

[0025] The DROP_NOTIFY packet carries packet loss sequence number information, the sending end enters the fast retransmission stage, and the CWR_REQ packet notifies the sending end of packet loss, and the sending end enters the window reduction stage;

[0026] The congestion control state comprises CA_Open, CA_Disorder, CA_CWR, CA_Recovery and CA_Loss states, respectively representing no congestion, occurrence of disorder, receipt of auxiliary congestion feedback, fast retransmission and timeout retransmission, and the identification is 0 to 4;

[0027] The sending end performs early congestion response, when the sending end responds to the first level of congestion control loop, the new congestion control level congState new is represented as:

[0028] congState new= max {congState old , congState'}

[0029] wherein congState old represents the original congestion control level, and congState' represents the target congestion control level of the first level of congestion control loop.

[0030] As a preferred scheme of the wide-area network TCP congestion control method based on early packet loss feedback according to the present application, wherein the retransmission of the data packet carrying the CWR flag by the sending end comprises:

[0031] When the sending end receives the DROP_NOTIFY packet, the packet segment corresponding to the sequence number is identified as lost by traversing the queue, and the end sequence number is calculated according to the IP header and TCP header response field and the start sequence number of the packet, which is expressed as:

[0032] payload_len = ip.tot_len - 4.ip.ihl - 4.tcp.th_off

[0033] seq end = seq start + payload_len - 1

[0034] wherein ip.tot_len represents the total length of the IP packet, ip.ihl represents the total length of the IP header, tcp.th_off represents the TCP payload offset, payload_len represents the TCP payload length, and seqstart represents the start sequence number of the lost packet carried in the DROP_NOTIFY packet;

[0035] If the marking is successful, the sending end attempts to enter CA_Recovery under the principle of congestion control level, otherwise the sending end attempts to enter CA_CWR;

[0036] The sending end notifies the transit device that the DROP_NOTIFY or CWR_REQ packet has been responded, and carries the CWR flag in the retransmitted TCP data packet.

[0037] As a preferred scheme of the wide-area network TCP congestion control method based on early packet loss feedback according to the present application, wherein the entering of CA_CWR by the sending end comprises:

[0038] The sending end sets a variable responseMark, and assigns responseMark as the sequence number SND.NXT of the next new data segment to be sent when responding to the CWR_REQ packet.

[0039] Before entering CWR_REQ, it is judged whether the current minimum unconfirmed sequence number SND.UNA is greater than responseMark, if yes, the response control is responded, otherwise the response is skipped.

[0040] As a preferred scheme of the wide area network TCP congestion control method based on early packet loss feedback, the sending end performing early congestion response further comprises:

[0041] After the sending end responds to the early congestion feedback, the transit device is informed to clear the notification state in the congestion hash table.

[0042] The sending end maintains a state variable RDN_state, which identifies whether the current is in the response of the first level of congestion control loop, wherein the value of RDN_state is 1, indicating that it is in the response state, and the value of RDN_state is 0, indicating that it is not in the response state.

[0043] When the congestion control is exited, i.e. the congestion control level is less than 2, if the value of the current RDN_State is 1, the RDN_State is set to 0.

[0044] In the second aspect, the application provides a wide area network TCP congestion control system based on early packet loss feedback, comprising,

[0045] A communication module is configured to establish a TCP connection between a sending end and a receiving end, and the sending end is configured to send a TCP data packet to the receiving end.

[0046] A packet generation module is configured to receive the TCP data packet at the transit device and forward it, and if the exit queue buffer reaches the discard threshold during the forwarding, mark that there is packet loss in the corresponding direction TCP flow, discard the TCP data packet and generate an RDN notification packet.

[0047] A control module is configured to send the RDN notification packet from the transit device to the sending end, receive and mark the corresponding data packet loss at the sending end, and enter a congestion control state.

[0048] A response module is configured to respond to the congestion notification and retransmit the data packet carrying the CWR flag at the sending end, and the transit device receives that the sending end has responded to the RDN loop and clears the congestion flag bit of the corresponding TCP flow.

[0049] In the third aspect, the application provides an electronic device, comprising:

[0050] A memory and a processor.

[0051] The memory is used for storing computer executable instructions, and the processor is used for executing the computer executable instructions, which realize the steps of the early packet loss feedback based wide area network TCP congestion control method.

[0052] In a fourth aspect, the present application provides a computer readable storage medium storing computer executable instructions, which realize the steps of the early packet loss feedback based wide area network TCP congestion control method when executed by a processor.

[0053] Compared with the prior art, the present application has the following beneficial effects: the present application designs a shorter early packet loss feedback control loop, which can significantly reduce the control delay under the long-distance characteristics of the wide area network, so that the sending end can more timely perceive congestion and respond, and reduce the occurrence of subsequent packet loss; by occupying less reverse link resources, the present application can accurately assist the sending end to retransmit the lost data segment, so that the sending end can recover from the fast retransmission more quickly, which is particularly obvious in the use scenario of a single long service flow; when the reverse link is congested or other reasons cause the loss of packet loss notification, the present application can still make the sending end enter the speed reduction through the auxiliary notification mechanism without increasing any load, thereby forming a reliable control mechanism; the principle of congestion control level is proposed and followed, so that the pre-control logic designed will not interfere with the behavior of the original congestion control, which embodies good robustness and practicability. BRIEF DESCRIPTION OF DRAWINGS

[0054] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without any creative labor. Among them:

[0055] Figure 1 The whole flowchart of the early packet loss feedback based wide area network TCP congestion control method according to an embodiment of the present application is shown in the figure;

[0056] Figure 2 The two-level control architecture diagram of the early packet loss feedback based wide area network TCP congestion control method according to an embodiment of the present application is shown in the figure;

[0057] Figure 3 The working flowchart of the early packet loss feedback based wide area network TCP congestion control method according to an embodiment of the present application is shown in the figure;

[0058] Figure 4 The simulation experiment architecture diagram of the early packet loss feedback based wide area network TCP congestion control method according to an embodiment of the present application is shown in the figure;

[0059] Figure 5 Google WebSearch traffic distribution diagram of the early packet loss feedback based WAN TCP congestion control method according to an embodiment of the present application;

[0060] Figure 6 Facebook Hadoop traffic distribution diagram of the early packet loss feedback based WAN TCP congestion control method according to an embodiment of the present application. DETAILED DESCRIPTION

[0061] In order to make the above objectives, features and advantages of the present application more apparent, specific embodiments of the present application will be described in detail below with the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work should fall within the protection scope of the present application.

[0062] In the following description, a large number of specific details are set forth in order to facilitate a thorough understanding of the present application. However, the present application can be implemented in other different manners than those described herein, and those skilled in the art can make similar generalizations without departing from the spirit and scope of the present application. Therefore, the present application is not limited to the specific embodiments disclosed below.

[0063] Secondly, the "one embodiment" or "embodiment" referred to herein means that a specific feature, structure or characteristic can be included in at least one implementation of the present application. The "in one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or alternative embodiment that excludes other embodiments.

[0064] The present application is described in detail in conjunction with the schematic diagram. In the detailed description of the embodiments of the present application, the cross-sectional view of the device structure is locally enlarged without the general proportion for the convenience of description, and the schematic diagram is only an example, which should not limit the protection scope of the present application herein. In addition, the three-dimensional spatial dimensions of length, width and depth should be included in the actual manufacture.

[0065] Meanwhile, in the description of the present application, it should be noted that the terms "up, down, in and out" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the indicated device or element must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first, second or third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.

[0066] Unless otherwise defined, the terms "mounting, connecting, associating" in the present application should be understood in a broad sense, for example: it can be fixed connection, detachable connection or integral connection; it can also be mechanical connection, electrical connection or direct connection, it can also be indirectly connected through intermediate medium, or it can be the internal communication of two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0067] Embodiment 1

[0068] Reference Figures 1-3 For an embodiment of the present application, a wide area network TCP congestion control method based on early packet loss feedback is provided, comprising:

[0069] S101, a TCP connection is established between the sending end and the receiving end, and the sending end sends TCP data packets to the receiving end.

[0070] It should be noted that considering the problem that long flows in wide area network cannot accurately locate the lost data segment during fast retransmission, a two-level control architecture for early feedback of packet loss is designed, a shorter congestion loop-RDN, to early notify the sending end of congestion, and the second level is a congestion control algorithm to handle congestion situations that cannot be handled by the first level. The implementation of the first level control loop is the interaction between the sending end and the transit device. The data transit device detects the occurrence of packet loss and notifies the sending end in advance through the control loop. The sending end responds in time, identifies the lost segment and enters the fast retransmission stage for accurate retransmission.

[0071] S102, the transit device receives the TCP data packet and forwards it, if the exit queue buffer reaches the discard threshold during forwarding, it marks that there is packet loss in the corresponding direction TCP flow, discards the TCP data packet and generates RDN notification packet.

[0072] Preferably, generating RDN notification packet comprises:

[0073] The RDN notification packet includes DROP_NOTIFY packet and CWR_REQ packet;

[0074] The transit device implements a reliable logic for notifying the receiving end of congestion packet loss. When the transit device receives a data packet, if there is no buffer capacity to forward the data packet, it generates DROP_NOTIFY packet through field editing for the data packet that should be discarded, including:

[0075] Discard the TCP payload and TCP option of the data packet, only keep the transport layer and previous header;

[0076] a four-tuple of the exchanged data packet, the four-tuple including a destination IP address, a source IP address, a destination port number, and a source port number;

[0077] recalculating an IP header and a TCP header checksum;

[0078] re-routing the data packet and placing the data packet in a high-priority queue of an egress port for preferential forwarding.

[0079] It should be noted that the DROP_NOTIFY packet obtained through the above steps is routed back to the sending end at the cost of a small overhead (less than 60 bytes) of the reverse link, while carrying the sequence number information of the lost packet, and the notification is earlier than the congestion control of the receiving end by a round-trip time of the transit device to the receiving end, achieving an early notification.

[0080] Since the transit device in the reverse link does not necessarily support the mechanism implemented by the present application, if the reverse link is congested after the RDN-supporting transit device generates the DROP_NOTIFY packet, the DROP_NOTIFY packet may be discarded, resulting in that the congestion information cannot be transmitted to the sending end in advance. In view of this problem, the present application simultaneously implements a reliable auxiliary notification mechanism CWR_REQ to ensure that the congestion information can reach the sending end when packet loss occurs.

[0081] The implementation of CWR_REQ requires the maintenance of a congestion marking hash table at the transit device, the key value of the hash table being a four-tuple of (source IP address, destination IP address, source port number, and destination port number), i.e., the identification of a TCP flow in one direction, and the value being 0 or 1, representing whether the flow in the direction needs to be notified of packet loss caused by congestion in the current situation, wherein 0 represents no need, and 1 represents the need. Considering that the concurrency of the flow is not the same in different application scenarios, the size of the hash table should also be adjusted according to the actual situation. Since the hash table only brings 1 bit of overhead for each item, in the case of no hash collision, the concurrency of the flow is proportional to the size of the hash table, so it can be well adapted to the cache of the transit device in the normal wide area network scenario.

[0082] Preferably, the congestion marking hash table is designed at the transit device, the value of the congestion hash table corresponding to the TCP flow is set to 1 when packet loss occurs at the transit device and a DROP_NOTIFY packet is generated, and the value of the congestion hash table corresponding to the TCP flow is set to 0 when the sending end responds to the control or the transit device receives a packet with a TCP FIN flag;

[0083] Based on the ACK returned by the receiving end, the transit device receives a TCP ACK packet;

[0084] read the congestion hash table key value of the TCP ACK message corresponding to the reverse direction TCP flow, i.e. the value of the four-tuple;

[0085] If the value is 1, the TCP ACK message carries CWR_REQ information, a CWR_REQ message is generated and forwarded to the sending end.

[0086] It should be noted that the above process can ensure that the sending end receives the early congestion feedback, and reliably informs the sending end of the congestion occurrence without causing overhead to the network.

[0087] In order to distinguish the DROP_NOTIFY message and the CWR_REQ message, the reserved field of the TCP header is used, which is located after the data offset field and at the 101st to 106th positions. Since only two special messages and original messages need to be distinguished, only the last two positions are used, which are referred to as RM. When RM=0b00, it is a normal message, when RM=0b01, it is a DROP_NOTIFY message, and when RM=0b02, it is a CWR_REQ message.

[0088] In S103, the transit device sends a RDN notification message to the sending end, and the sending end receives and marks the corresponding data message loss and enters the congestion control state.

[0089] Preferably, the sending end receiving and marking the corresponding data message loss and entering the congestion control state includes:

[0090] The sending end responds to the DROP_NOTIFY and CWR_REQ messages arriving from the transit device;

[0091] The DROP_NOTIFY message carries the packet loss sequence number information, the sending end enters the fast retransmission stage, and the CWR_REQ message informs the sending end of the occurrence of packet loss, and the sending end enters the window reduction stage.

[0092] It should be noted that in the first level congestion control loop, the sending end is responsible for responding to the DROP_NOTIFY and CWR_REQ messages arriving from the transit device. The DROP_NOTIFY carries accurate packet loss sequence number information, and the sending end must enter the fast retransmission stage (CA_Recovery). The CWR_REQ can only inform the sending end of the occurrence of packet loss and does not carry additional information, so the sending end cannot blindly retransmit the message and can only enter the window reduction stage (CA_CWR).

[0093] The TCP congestion control in the Linux kernel can be divided into five states, the congestion control states include CA_Open, CA_Disorder, CA_CWR, CA_Recovery and CA_Loss states, which respectively represent no congestion, occurrence of disorder, receipt of auxiliary congestion feedback, fast retransmission and timeout retransmission, and the congestion degree is gradually increased, and the identification is 0 to 4;

[0094] Since the congestion control is closely related to the timing, the network can also be in a congestion state when the first level control is triggered, at this time, a principle must be followed, that is, the congestion control level cannot be reduced due to early congestion feedback. Assuming that the sending end performs early congestion response, when the sending end responds to the first level congestion control loop, the new congestion control level congState new is represented as:

[0095] congState new = max{congState old , congState'}

[0096] Wherein, congState old represents the original congestion control level, and congState' represents the target congestion control level of the first level congestion control loop (as mentioned above, DROP_NOTIFY is 3, and CWR_REQ is 2), following the principle, the early congestion response of the first level congestion control loop can be performed without affecting the second level congestion control loop.

[0097] Preferably, the sending end retransmits the data message carrying the CWR flag, which includes:

[0098] When the sending end receives the DROP_NOTIFY message, since a retransmission queue is dynamically maintained based on the SACK mechanism in the Linux kernel implementation, which contains all unconfirmed message segments, the message segment corresponding to the sequence number can be identified as lost by traversing the queue, which is convenient for subsequent retransmission. The start sequence number of the lost message segment can be obtained in the DROP_NOTIFY message. Since the length field of the IP and TCP header is not modified when generating DROP_NOTIFY, the end sequence number can be calculated according to the IP header and TCP header response field and the start sequence number of the message, which is represented as:

[0099] payload_len = ip·tot_len - 4·ip·ihl - 4·tcp.th_off

[0100] seq end = seq start + payload_len - 1

[0101] wherein ip-tot_len represents the total length of the IP packet, ip-ihl represents the total length of the IP header, tcp.th_off represents the TCP payload offset, payload_len represents the TCP payload length, seq represents the initial sequence number of the lost packet carried in the DROP_NOTIFY packet, and ack represents the initial acknowledgement number of the lost packet carried in the DROP_NOTIFY packet. start represents the initial sequence number of the lost packet carried in the DROP_NOTIFY packet;

[0102] If the marking is successful, the sender attempts to enter CA_Recovery under the principle of congestion control level, otherwise, it takes similar logic as receiving CWR_REQ, and the sender attempts to enter CA_CWR because there is no accurate packet loss guide.

[0103] The sender notifies the transit device that it has responded to the DROP_NOTIFY or CWR_REQ packet, and carries the CWR mark in the retransmitted TCP data packet.

[0104] It should be noted that in order to notify the transit device that the sender has responded to the DROP_NOTIFY or CWR_REQ packet, the embodiment adopts a similar strategy as ECN, and carries the CWR mark in the subsequent transmitted TCP data packet, but it is different from the ECN, because the direct manifestation of the DROP_NOTIFY packet is to trigger retransmission, so the retransmitted packet should also be marked with CWR.

[0105] Preferably, the sender entering CA_CWR includes:

[0106] The sender sets the variable responseMark, and assigns responseMark to the sequence number SND.NXT of the next new data segment to be sent when responding to the CWR_REQ packet.

[0107] Before entering CWR_REQ, it is judged whether the current smallest unconfirmed sequence number SND.UNA is greater than responseMark, if it is greater, the response is controlled, otherwise, the response is skipped.

[0108] It should be noted that when receiving the reliable auxiliary notification mechanism CWR_REQ, unlike directly attempting to enter congestion control when receiving DROP_NOTIFY, in order to prevent the problem of over-decreasing the speed of the forward link caused by the reverse link congestion, the embodiment provides that the CWR_REQ is responded at most once in a sending window, because CA_CWR is an important logic implemented in the Explicit Congestion Notification (ECN) mechanism, in order to be coupled with the ECN-based congestion control, the same judgment strategy is adopted before entering CA_CWR, although the explicit congestion notification needs the support of all switches along the way, and it is almost impossible to be deployed in a wide area network, but in order to design the robustness, this problem is still considered.

[0109] Preferably, the sending end notifies the transit device to clear the notification state in the congestion hash table after responding to the early congestion feedback;

[0110] The sending end maintains a state variable RDN_state to identify whether it is currently in the response of the first level of congestion control loop, wherein the value of RDN_state is 1 indicates that it is in the response state, and the value of RDN_state is 0 indicates that it is not in the response state.

[0111] When the congestion control level is less than 2, if the current value of RDN_State is 1, RDN_State is set to 0.

[0112] S104, the sending end retransmits the data message carrying the CWR flag, and the transit device receives that the sending end has responded to the RDN loop, and clears the congestion flag bit of the corresponding TCP flow.

[0113] Preferably, when the sending end responds to the control or the transit device receives the message with the TCP FIN flag, the value of the congestion hash table of the corresponding TCP flow is set to 0.

[0114] Specifically, the transit device receives the TCP data message with the CWR flag or the FIN flag, and the transit device acquires the subscript corresponding to the congestion flag bit of the TCP flow according to the four-tuple, and clears the value at the congestion flag bit of the corresponding TCP flow to 0.

[0115] It should be noted that, corresponding to the congestion hash table at the transit device, the sending end needs to notify the transit device to clear the notification state in the hash table after responding to the early congestion feedback, which requires the sending end to maintain a state variable to identify whether it is currently in the response of the first level of congestion control loop, and this case only occurs when the sending end receives ACK.

[0116] The application designs a shorter early packet loss feedback control loop, which can significantly reduce the control delay under the long-distance characteristics of the wide area network, so that the sending end can perceive congestion and react more timely, and reduce the occurrence of subsequent packet loss. By occupying less reverse link resources, the application accurately assists the sending end to retransmit the lost data segment, so that the sending end can recover from the fast retransmission more quickly, which is particularly obvious in the use scenario of one-way long service flow. When the reverse link is congested or other reasons cause the loss of packet loss notification, the application can still make the sending end enter the speed reduction in advance through the auxiliary notification mechanism without increasing any load, forming a reliable control mechanism. The application proposes and follows the principle of congestion control level, so that the designed pre-control logic does not interfere with the behavior of the original congestion control, and has good robustness and practicality.

[0117] The above is a schematic scheme of the wide area network TCP congestion control method based on early packet loss feedback of the embodiment. It should be noted that the technical scheme of the wide area network TCP congestion control system based on early packet loss feedback belongs to the same concept as the technical scheme of the wide area network TCP congestion control method based on early packet loss feedback. The details of the technical scheme of the wide area network TCP congestion control system based on early packet loss feedback in the embodiment are not described in detail, and can be referred to the description of the technical scheme of the wide area network TCP congestion control method based on early packet loss feedback.

[0118] The wide area network TCP congestion control system based on early packet loss feedback in the embodiment comprises:

[0119] The communication module is configured to establish a TCP connection between the sending end and the receiving end, and the sending end is configured to send TCP data packets to the receiving end.

[0120] The packet generation module is configured to receive TCP data packets at the transit device and forward the TCP data packets. If the exit queue buffer reaches the discard threshold during the forwarding, it is marked that there is packet loss for the TCP flow in the corresponding direction, the TCP data packet is discarded, and an RDN notification packet is generated.

[0121] The control module is configured to send the RDN notification packet to the sending end by the transit device, and the sending end receives and marks the corresponding data packet loss, and enters the congestion control state.

[0122] The output module is configured to retransmit the data packet carrying the CWR flag by the sending end, and the transit device receives that the sending end has responded to the RDN loop, and clears the congestion flag bit of the corresponding TCP flow.

[0123] The embodiment also provides an electronic device suitable for the wide area network TCP congestion control based on early packet loss feedback, comprising:

[0124] The memory is configured to store computer executable instructions, and the processor is configured to execute the computer executable instructions to implement the wide area network TCP congestion control method based on early packet loss feedback as described in the above embodiment.

[0125] The embodiment also provides a storage medium having a computer program stored thereon, which is executed by a processor to implement the wide area network TCP congestion control method based on early packet loss feedback as described in the above embodiment.

[0126] The storage medium proposed in the embodiment belongs to the same inventive concept as the wide area network TCP congestion control method based on early packet loss feedback proposed in the above embodiment. The technical details not described in detail in the embodiment can be referred to the above embodiment, and the embodiment has the same beneficial effects as the above embodiment.

[0127] Through the above description of the embodiments, those skilled in the art can clearly understand that the present application can be realized by means of software and necessary universal hardware, and of course can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a floppy disk, a read-only memory (ROM), a random access memory (RAM), a FLASH memory, a hard disk, or an optical disc, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of various embodiments of the present application.

[0128] Embodiment 2

[0129] Referring to Table 1 and Figures 4-6 For an embodiment of the present application, a wide-area network TCP congestion control method based on early packet loss feedback is provided, and comparative results of two schemes are provided to verify the beneficial effects thereof.

[0130] In this embodiment, 80% load Google WebSearch and Facebook Hadoop traffic distribution are used, as shown in Table 1, and simulation experiments are performed in an 8-to-1 scenario at 10 Gbps, as shown in Figure 4 .

[0131] Table 1: Traffic distribution table

[0132] Flow distribution Flow number Total length (MB) Google Web Search 2298 4102.11 FB Hadoop 33257 3856.97

[0133] From the experimental results of Figure 5 , Figure 6 , it can be seen that the flow completion time (FCT) of TCP Cubic is optimized, CUBIC with RDN implements the method of the present application, CUBIC w / o RDN does not implement the method of the present application, the link delay is 10 ms, the round-trip time RTT is 40 ms, and the average FCT is reduced, and the effect is more obvious on Google WebSearch traffic distribution.

[0134] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not limiting, and although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present application, and they should be covered in the scope of the claims of the present application.

Claims

1. A method for WAN TCP congestion control based on early packet loss feedback, characterized in that, Comprise: A TCP connection is established between a sending end and a receiving end, and the sending end sends TCP data packets to the receiving end; The TCP data packets are received at a transit device and forwarded, and if the egress queue buffer reaches the discard threshold when forwarding, it is marked that there is packet loss for the TCP flow in the corresponding direction, the TCP data packets are discarded, and an RDN notification packet is generated; The transit device sends the RDN notification packet to the sending end, the sending end receives and marks the corresponding data packet loss, and enters the congestion control state; The sending end retransmits the data packet carrying the CWR flag, and the transit device receives the data packet carrying the CWR flag and clears the congestion flag bit of the corresponding TCP flow; The RDN notification packet includes a DROP_NOTIFY packet and a CWR_REQ packet; The CWR_REQ packet includes: A congestion marking hash table is designed at the transit device, and when packet loss occurs at the transit device and a DROP_NOTIFY packet is generated, the congestion hash table value of the corresponding TCP flow is set to 1; Based on the ACK returned by the receiving end, the transit device receives the TCP ACK packet; Read the congestion hash table key value of the reverse direction TCP flow corresponding to the TCP ACK packet, that is, the value of the four-tuple; If the value is 1, the TCP ACK packet carries the CWR_REQ information, the CWR_REQ packet is generated, and is forwarded to the sending end; The sending end receives and marks the corresponding data packet loss, and enters the congestion control state, which includes: The sending end responds to the DROP_NOTIFY and CWR_REQ packets arriving from the transit device; The DROP_NOTIFY packet carries the packet loss sequence number information, the sending end enters the fast retransmission stage, and the CWR_REQ packet notifies the sending end that packet loss has occurred, and the sending end enters the window reduction stage; The congestion control state includes CA_Open, CA_Disorder, CA_CWR, CA_Recovery and CA_Loss states, respectively indicating no congestion, occurrence of disorder, receipt of auxiliary congestion feedback, fast retransmission and timeout retransmission, and the identification is 0 to 4; The sending end performs early congestion response, and the sending end responds to the CWR_REQ message, and a new congestion control level congState new is represented as: congState new = max{congState old , congState'} congState = congState + (congState - congState') / congState old congState = congState + (congState - congState') / congState congState = congState + (congState - congState') / congState 2. The TCP congestion control method based on early packet loss feedback for wide area networks as claimed in claim 1, wherein, Generating an RDN notification packet includes: When the transit device receives a data packet, if there is no buffer capacity to forward the data packet, the data packet that should be discarded is generated into a DROP_NOTIFY packet through field editing, which includes: Discard the TCP payload and TCP option of the data packet, only keep the transport layer and previous header; Exchange the four-tuple of the data packet, which includes the destination IP address, source IP address, destination port number and source port number; Recalculate the IP header and TCP header checksum; The data packet is re-routed and put into the high priority queue of the egress port for priority forwarding.

3. The TCP congestion control method based on early packet loss feedback for wide area networks as claimed in claim 1 or 2, wherein, The sending end retransmits the data packet carrying the CWR flag, which includes: When the sending end receives the DROP_NOTIFY packet, the packet segment corresponding to the sequence number is marked as lost by traversing the queue, the end sequence number is calculated according to the IP header and the TCP header response field and the starting sequence number of the packet, and is expressed as: payload_len=ip.tot_len-4·ip.ihl-4·tcp.th_off seq end = seq start + payload len - 1 Wherein, ip.tot_len represents the total length of the IP packet, ip.ihl represents the total length of the IP header, tcp.th_off represents the TCP payload offset, payload_len represents the TCP payload length, seq start represents the start sequence number of the lost packet carried in the DROP_NOTIFY packet; If the marking is successful, the sending end attempts to enter CA_Recovery under the principle of following the congestion control level, otherwise the sending end attempts to enter CA_CWR; The sending end notifies the transit device that it has responded to the DROP_NOTIFY or CWR_REQ packet, and carries the CWR flag in the retransmitted TCP data packet.

4. The TCP congestion control method based on early packet loss feedback for wide area networks as claimed in claim 3, wherein, The sending end enters CA_CWR, which includes: The sending end sets the variable responseMark, which is assigned to the sequence number SND.NXT of the next new data segment to be sent when responding to the CWR_REQ packet. Before entering CWR_REQ, it is judged whether the current smallest unconfirmed sequence number SND.UNA is greater than responseMark, if it is greater, the response is controlled, otherwise this response is skipped.

5. The TCP congestion control method based on early packet loss feedback for wide area networks as claimed in claim 4, wherein, The sending end performing early congestion response also includes: After the sending end responds to the early congestion feedback, it notifies the transit device to clear the notification state in the congestion hash table; The sending end maintains a state variable RDN_state to identify whether it is currently in the response of the CWR_REQ packet, wherein the value of RDN_state is 1, indicating that it is in the response state, and the value of RDN_state is 0, indicating that it is not in the response state; When exiting the congestion control, i.e., the final congestion control level is CA_Open, if the value of RDN_State is 1, RDN_State is set to 0.

6. A system for TCP congestion control in wide area networks based on early packet loss feedback, characterized in that, including, The communication module is used for establishing a TCP connection between the sending end and the receiving end, and the sending end sends a TCP data packet to the receiving end; The packet generation module is used for receiving the TCP data packet at the transit device and forwarding it, if the egress queue buffer reaches the discard threshold during forwarding, marking that there is packet loss for the corresponding direction TCP flow, discarding the TCP data packet and generating an RDN notification packet; The control module is used for the transit device to send the RDN notification packet to the sending end, and the sending end receives and marks the corresponding data packet as lost, and enters the congestion control state; The response module is used for the sending end to respond to the congestion notification and retransmit the data packet carrying the CWR flag, and the transit device receives that the sending end has responded to the RDN loop and clears the congestion flag bit of the corresponding TCP flow; The RDN notification packet includes DROP_NOTIFY packet and CWR_REQ packet; The CWR_REQ packet includes: The transit device designs a congestion marking hash table, when packet loss occurs at the transit device and a DROP_NOTIFY packet is generated, the congestion hash table value of the corresponding TCP flow is set to 1; Based on the ACK returned by the receiving end, the transit device receives the TCP ACK packet; reading a congestion hash table key value, i.e. a value of a four-tuple, of a reverse TCP flow corresponding to the TCP ACK packet; if the value is 1, making the TCP ACK packet carry CWR_REQ information, generating the CWR_REQ packet, and forwarding to a sending end; the sending end receiving and marking a corresponding data packet loss, and entering a congestion control state, including: the sending end responding to a DROP_NOTIFY and CWR_REQ packet arriving from a transit device; the DROP_NOTIFY packet carrying packet loss sequence number information, the sending end entering a fast retransmission stage, and the CWR_REQ packet notifying the sending end of packet loss, the sending end entering a window reduction stage; the congestion control state including CA_Open, CA_Disorder, CA_CWR, CA_Recovery, and CA_Loss states, respectively representing no congestion, occurrence of disorder, receipt of auxiliary congestion feedback, fast retransmission, and timeout retransmission, and being identified as 0 to 4; The sending end performs early congestion response, and the sending end responds to the CWR_REQ message, and a new congestion control level congState new is represented as: congState new = max{congState old , congState'} congState = congState + (congState - congState') / congState old congState = congState + (congState - congState') / congState congState = congState + (congState - congState') / congState 7. An electronic device, comprising: including: a memory and a processor; the memory being used to store computer executable instructions, and the processor being used to execute the computer executable instructions, the computer executable instructions, when executed by the processor, realizing steps of the wide area network TCP congestion control method based on early packet loss feedback according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, having stored computer executable instructions, the computer executable instructions, when executed by the processor, realizing steps of the wide area network TCP congestion control method based on early packet loss feedback according to any one of claims 1 to 5.

Images