System and method for congestion and traffic control in network

Abstract

The invention relates to a system and method for congestion and traffic control in a network. The congestion window is controlled by a receiving end in the communication network and then provided to a transmitting end to control packet traffic within the network. The congestion window may be dynamically adjusted based on detection of one of a packet loss, a congestion signal, and a packet delay signal. The congestion window may be further adjusted based on bandwidth usage to achieve fairness or traffic control. And the sending end node receives the congestion window and controls the sending rate according to the congestion window. The sending end node can determine packet loss and further adjust the congestion window.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for providing congestion control and flow control in a network, particularly for using a receiving end node to determine the congestion window of a sending end node. Background Art

[0002] Network communication protocols such as the Transmission Control Protocol (TCP) may include flow rate control of packets sent by a sending end to reduce congestion problems. The sending end may send TCP packets and adjust the sending rate according to observable events such as packet loss. Congestion control at the sending end may use existing schemes such as the Additive Increase / Multiplicative Decrease (AIMD) method. Summary of the Invention

[0003] The present disclosure relates to systems and methods for providing congestion control and flow control in a network, particularly for using a receiving end node to determine the congestion window of a sending end node.

[0004] By performing congestion control and flow control determination at the receiving end node, the congestion control and flow control determination can be based on more complete information about network conditions, rather than just based on packet loss. The more complete information can explain the behavior of multiple sending end nodes. In addition, the congestion control and flow control can be based on one-way delay values, which may be more accurate compared to the round-trip time (RTT)-based method required when the sending end is responsible for congestion control. Additionally, combining congestion control and flow control so that they are performed together can improve efficiency and ensure that congestion control and flow control do not conflict with each other.

[0005] In an embodiment, a computer network includes a receiving end node configured to receive data packets from one or more sending end nodes. The receiving end node is configured to determine network congestion. The receiving end node is further configured to determine the congestion window of one or more sending end nodes based on the determination of network congestion and transmit the congestion window to one or more sending end nodes.

[0006] In an embodiment, the receiving end node is configured to detect packet loss in data packets received from one or more sending end nodes, detect Explicit Congestion Notification (ECN) in data packets received from one or more sending end nodes, and determine the one-way delay of data packets received from one or more sending end nodes.

[0007] In an embodiment, the computer network further includes one or more sending nodes, and wherein each of the one or more sending nodes is configured to receive the congestion window of the sending node from a receiving node, and control the sending of packets from the sending node based on the congestion window. In an embodiment, at least some of the one or more sending nodes are configured to detect packet loss of the first packet and the last packet in the data packets sent from the sending node to the receiving node, and reduce the congestion window when detecting packet loss of the first packet and the last packet.

[0008] In an embodiment, the receiving node is configured to determine the one-way delay by determining the difference between the time at the receiving end and the timestamps when multiple packets in the data packets are sent from one or more sending nodes.

[0009] In an embodiment, the receiving node is configured such that when the receiving node detects packet loss, the receiving node determines to reduce the congestion window.

[0010] In an embodiment, the receiving node is configured such that when the receiving node does not detect packet loss and the receiving node detects ECN, the receiving node determines to reduce the congestion window.

[0011] In an embodiment, the receiving node is configured such that when the receiving node does not detect packet loss and the receiving node does not detect ECN, compare the one-way delay with the target one-way delay, and when the one-way delay exceeds the target one-way delay, the receiving node determines to reduce the congestion window.

[0012] In an embodiment, the receiving node is further configured to adjust the congestion window of the corresponding sending node based on a comparison between the bandwidth of the flow from the corresponding sending node among one or more sending nodes and the average bandwidth of the flows from the one or more sending nodes. In an embodiment, different sending nodes among the one or more sending nodes have different priorities, and the receiving node is configured to adjust the congestion window based on the priority of the corresponding sending node.

[0013] In an embodiment, a method for controlling traffic in a computer network includes: determining network congestion at a receiving node configured to receive data packets from one or more sending nodes. The method further includes: determining the congestion window of one or more sending nodes at the receiving node based on the determination of network congestion.

[0014] In an embodiment, determining congestion on a network includes: detecting packet loss in packets received from one or more sending end nodes. The method further includes: at a receiving end node, detecting explicit congestion notification (ECN) in packets received from one or more sending end nodes. The method also includes: at a receiving end node, determining the one-way delay of packets received from one or more sending end nodes.

[0015] In an embodiment, the method further includes: at one or more sending end nodes, receiving the congestion window of the sending end node from the receiving end node, and operating the sending end node to send packets to the receiving end node based on the congestion window. In an embodiment, the method further includes: at one or more sending end nodes, detecting packet loss of the first packet and the last packet in the packets sent from the sending end node to the receiving end node, and reducing the congestion window when packet loss of the first packet and the last packet is detected.

[0016] In an embodiment, determining the one-way delay includes determining the difference between the time at the receiving end and the timestamps when multiple packets in the packets sent from one or more sending end nodes are sent.

[0017] In an embodiment, when the receiving end node detects packet loss, the receiving end node determines to reduce the congestion window.

[0018] In an embodiment, when the receiving end node does not detect packet loss and the receiving end node detects ECN, the receiving end node determines to reduce the congestion window.

[0019] In an embodiment, when the receiving end node does not detect packet loss and the receiving end node does not detect ECN, the one-way delay is compared with a target one-way delay, and when the one-way delay exceeds the target one-way delay, the receiving end node determines to reduce the congestion window.

[0020] In an embodiment, the method further includes adjusting the congestion window of the corresponding sending end node based on a comparison between the bandwidth of the flow from the corresponding sending end node among one or more sending end nodes and the average bandwidth of the flows from one or more sending end nodes.

[0021] In an embodiment, different sending end nodes among one or more sending end nodes have different priorities, so as to adjust the congestion window based on the priorities of the corresponding sending end nodes.

[0022] In an embodiment, a non-transitory computer-readable medium stores computer-executable instructions thereon that, when executed, cause one or more processors of a receiving end node of a computer network to perform operations including: detecting explicit congestion notification (ECN) in data packets received from one or more sending end nodes; determining a one-way delay of data packets received from one or more sending end nodes; determining a congestion window of one or more sending end nodes based on at least one of packet loss detection, ECN detection, or one-way delay; and transmitting the congestion window from the receiving end node to one or more sending end nodes.

[0023] In an embodiment, determining the congestion window includes: when the receiving end node detects packet loss, determining to decrease the congestion window. Determining the congestion window further includes: when the receiving end node does not detect packet loss and the receiving end node detects ECN, determining to decrease the congestion window. Determining the congestion window also includes: when the receiving end node does not detect packet loss and the receiving end node does not detect ECN, comparing the one-way delay with a target one-way delay, and when the one-way delay exceeds the target one-way delay, determining to decrease the congestion window.

[0024] In an embodiment, a computer network includes a receiving end node configured to receive data packets from one or more sending end nodes. The receiving end node is configured to: dynamically adjust a congestion window to be sent to one or more sending end nodes based on detection of one of packet loss, a congestion signal, and a packet delay signal from one or more sending end nodes, and transmit the congestion window to one or more sending end nodes.

[0025] In an embodiment, a method for controlling traffic in a computer network includes: at a receiving end node configured to receive data packets from one or more sending end nodes, dynamically adjusting a congestion window to be sent to one or more sending end nodes based on detection of one of packet loss, a congestion signal, and a packet delay signal from one or more sending end nodes, and transmitting the congestion window from the receiving end node to one or more sending end nodes.

[0026] In an embodiment, a non-transitory computer-readable medium stores computer-executable instructions thereon that, when executed, cause one or more processors of a receiving end node of a computer network to perform operations. The operations include: dynamically adjusting a congestion window to be sent to one or more sending end nodes based on detection of one of packet loss, a congestion signal, and a packet delay signal from one or more sending end nodes, and transmitting the congestion window from the receiving end node to one or more sending end nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The accompanying drawings illustrate various embodiments of the systems and methods of the present disclosure, as well as embodiments of various other aspects. Any ordinary person skilled in the art will understand that the element boundaries shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent an example of a boundary. In some examples, it may be possible that one element can be designed as multiple elements, or multiple elements can be designed as one element. In some examples, an element that is shown as an internal component of one element can be implemented as an external component of another element, and vice versa. A non-limiting and non-exhaustive description is provided with reference to the following accompanying drawings. The components in the figures are not necessarily drawn to scale, but emphasis is placed on illustrating the principles. In the following detailed description, the embodiments are described only by way of illustration, as various changes and modifications may be apparent to those skilled in the art from the following detailed description.

[0028] Figure 1 A network according to an embodiment is shown.

[0029] Figure 2 A schematic diagram of a congestion and traffic control system according to an embodiment is shown.

[0030] Figure 3 A flowchart of a method according to an embodiment is shown. Detailed Description

[0031] The present disclosure relates to systems and methods for providing congestion control and traffic control in a network, particularly using a receiving end node to determine the congestion window of a sending end node.

[0032] In the following detailed description, specific embodiments of the present disclosure are described herein with reference to the accompanying drawings, which form a part of this specification. In this specification and the accompanying drawings, unless the context otherwise requires, the same reference numerals denote elements that can perform the same, similar, or equivalent functions. Additionally, unless otherwise stated, the description of each subsequent drawing can refer to features from one or more of the previous drawings to provide a clearer context and a more substantial explanation for the current exemplary embodiment. Nevertheless, the exemplary embodiments described in the detailed description, the drawings, and the claims are not intended to be limiting. Other embodiments can be utilized and other changes can be made without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that the various aspects of the present disclosure, as generally described herein and shown in the accompanying drawings, can be arranged, substituted, combined, separated, and designed in a wide variety of configurations, all of which are explicitly contemplated herein.

[0033] It should be understood that the disclosed embodiments are merely examples of the present disclosure, which can be embodied in various forms. Well-known functions or configurations are not described in detail to avoid obscuring the present disclosure with unnecessary details. Therefore, the specific structural and functional details disclosed herein should not be construed as restrictive, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to employ the present disclosure in various ways in almost any appropriate detailed structure.

[0034] Additionally, the present disclosure may be described herein in terms of functional block components and various processing steps. It should be understood that such functional blocks can be implemented by any number of hardware and / or software components configured to perform the specified functions.

[0035] The scope of the present disclosure should be determined by the appended claims and their legal equivalents, rather than by the examples given herein. For example, the steps recited in any method claim can be performed in any order, without being limited to the order presented in the claim. Additionally, no element is essential to the practice of the present disclosure unless explicitly described herein as "critical" or "necessary".

[0036] As mentioned herein, "congestion window" is a technical term referring to the control of the transmission rate of the sending end node of a network. In particular, the congestion window can be a limit on the total number of unacknowledged packets for a single transmission. When the number of unacknowledged packets reaches or exceeds the congestion window, the sending end can stop sending data until an acknowledgment is received. The term congestion window can be abbreviated as CWND. As used herein, when the congestion window increases (i.e., is adjusted upward), the amount of unacknowledged packets from the sending end can increase. The ability to send more packets without acknowledgment can thus increase the transmission rate of the sending end. Increasing the transmission rate of the sending end node can facilitate faster data exchange on the network. As used herein, when the congestion window decreases (i.e., is adjusted downward), the number of unacknowledged packets before the transmission pause decreases. Thus, the reduction in the number of unacknowledged packets allowed before sending additional packets can reduce the transmission rate of the sending end node of the network. Reducing the transmission rate of the sending end node can reduce network congestion, as well as reduce packet loss, buffer filling, other delays, etc., thereby improving communication efficiency on the network.

[0037] Figure 1 A network according to an embodiment is shown. Network 100 includes a sending end 102, a plurality of switches 104, and a receiving end 106. The plurality of switches provide a plurality of traffic paths 108 between the sending end node 102 and the receiving end node 106. Network 100 is a network on which the congestion and traffic control described herein can be implemented. As Figure 1As shown, network 100 is a multi-path network that includes multiple traffic paths 108 from a sending end 102 to a receiving end 106. It should be understood that the congestion and flow control described herein can be applied to a single-path or multi-path network 100 to manage the packet sending rate of the sending end 102 based on a congestion window determined at the receiving end 106 based on received packets. In an alternative embodiment, network 100 can alternatively be any suitable network that allows data packets to be transmitted from the sending end 102 to the receiving end 106.

[0038] The sending end 102 transmits data packets through the network 100 to the receiving end 106. The sending end 102 can be, for example, a server, any other suitable computer, a personal device such as a smart phone, a tablet computer, etc., and so on. The data packets can be packets that follow any suitable data transmission protocol (such as TCP). The sending end 102 further receives acknowledgments for the received packets according to the protocol used. When the sending end 102 transmits packets at a rate exceeding the bottleneck capacity of the network 100, a router at the bottleneck (such as one of the switches 104) can put the packets into a buffer. If the sending end 102 provides packets at a rate faster than the rate at which the packets can leave the buffer, the buffer will be filled, and eventually when there is no capacity in the buffer, the packets will be discarded. In Figure 1 the embodiment shown, the sending end 102 is further configured to obtain a congestion window from the acknowledgments received from the receiving end 106. The congestion window manages the behavior of the sending end 102 by restricting the number of packets that can be sent without acknowledgment within a given time. When the congestion window increases, the sending rate of the sending end 102 can increase, and when the congestion window decreases, the sending rate of the sending end can decrease. In an embodiment, the sending end 102 can be configured to detect packet loss, for example, when no acknowledgment for the sent packets is received. In an embodiment, the sending end 102 can be configured to attach a congestion signal to the packets being sent when congestion occurs. A non-limiting example of the congestion signal is explicit congestion notification (ECN). In an embodiment, the sending end 102 can be configured to detect packet loss for packets for which the receiving end 106 may not be able to observe packet loss (such as the first or last packet of a specific data stream from the sending end 102 to the receiving end 106). In such an embodiment, the sending end 102 can be configured to adjust the congestion window at the sending end 102 based on packet loss detection at the sending end 102 without requiring the congestion window provided in the acknowledgments from the receiving end 106. A non-limiting example of adjusting the congestion window at the sending end 102 in response to detected packet loss will be further described with reference to Figure 3 step 320 of method 300 shown and described below.

[0039] Multiple switches 104 may be provided between the sending end 102 and the receiving end 106 to define multiple traffic paths 108. In an embodiment, a routing protocol may be used to split traffic across multiple traffic paths 108 according to Multipath TCP. In an alternative embodiment, packets may be transmitted from the sending end 102 to the receiving end 106 through any suitable single traffic path, such as according to known TCP / IP protocols. In the embodiments described herein, congestion and flow control may be implemented by the sending end 102 and the receiving end 106 without regard to one or more traffic paths 108 therebetween or components of such traffic paths 108, such as switches 104.

[0040] The receiving end 106 is configured to receive a data stream from the sending end 102 through one or more of the traffic paths 108. The receiving end 106 may be, for example, a server, any other suitable computer, a personal device such as a smart phone, a tablet computer, etc., and so on. The receiving end 106 is configured to receive packets of the data stream from the sending end 102 and determine a congestion window based on the characteristics and / or content of the packets. For example, the receiving end 106 may be configured to detect congestion and reduce the congestion window based on one or more of packet loss detection, detection of congestion signals attached to the packets, and / or latency (such as the one-way latency of the received packets). The determined congestion window may be transmitted to the sending end 102 to manage future packet transmissions by the sending end 102. In an embodiment, the determined congestion window may be included in, appended to, or sent together with the packet acknowledgments sent from the receiving end 106 to the sending end 102. In an embodiment, the receiving end 106 may include one or more latency calculators, congestion window calculators, and / or flow control and fairness modules as discussed below and as Figure 2 shown. In a non-limiting example, the receiving end 106 may be configured to determine the congestion window according to method 300 as Figure 3 shown and discussed below.

[0041] Figure 2 FIG. shows a schematic diagram of a congestion and flow control system according to an embodiment. The congestion and flow control system 200 is provided at the receiving end 202. The receiving end 202 communicates with one or more sending ends 204. The congestion and flow control system 200 includes (multiple) latency calculators 206 for each of the (multiple) sending ends 204. The congestion and flow control system 200 further includes (multiple) congestion window calculators 208 for each of the (multiple) sending ends 204. The congestion and flow control system 200 includes (multiple) flow control and fairness modules 210. The congestion and flow control system further includes (multiple) congestion window token generators 212.

[0042] The congestion and flow control system 200 is a system configured to allow data packets to be sent from one or more senders 204 to a receiver 202. The congestion and flow control system 200 may include any suitable hardware, software, combinations thereof, etc., such that data packets can be transmitted from the sender(s) 204 to the receiver 202.

[0043] The receiver 202 is configured to receive data from one or more senders 204. The receiver 202 may include, for example, a server, any other suitable computer, personal devices such as a smart phone, a tablet computer, etc., and so on. The receiver 202 may have a suitable data connection with one or more senders 204, such as any suitable wired or wireless connection to one or more of the Internet, a local network (such as an intranet), etc. The receiver 202 may receive data packets from the sender(s) 204 using any suitable protocol (such as the TCP / IP protocol). The receiver 202 may include a plurality of modules, which include any suitable hardware, software, or combinations thereof. The plurality of modules included in the receiver 202 may include one or more delay calculators 206, one or more congestion window calculators 208, one or more flow control and fairness modules 210, and / or one or more congestion window token generators 212, as further discussed below.

[0044] (Multiple) senders 204 are configured to send data packets to a receiver 202. The (multiple) senders 204 can be nodes of a network including the receiver 202. The (multiple) senders can be any suitable data packet source. The sender 204 can send data packets to the receiver 202 according to any suitable protocol, through any suitable hardware, software, and their combination. Data packets from the sender 204 can reach the receiver through any suitable layer and / or path (e.g., multiple layers of the TCP / IP model). There can be multiple senders 204, and each sender sends packets to the receiver 202 through a corresponding suitable network. The network by which the sender 204 sends packets to the receiver 202 can include one or more of the Internet, a local network (such as an intranet), etc. The network by which the sender 204 sends packets to the receiver 202 can include any one or more suitable methods for transmitting and receiving data packets (such as any suitable wired or wireless connection), and can include any suitable hardware, software, their combination, etc. to allow the transmission of data packets from the (multiple) senders 204 to the receiver 202. The sender 204 is configured to receive an acknowledgment from the receiver after the receiver 202 receives a packet from the sender. Each of the senders 204 can control its respective packet sending rate based on a congestion window and the acknowledgment, where the congestion window manages the number of packets that can be sent without an acknowledgment from the receiver 202. The (multiple) senders 204 in the congestion and flow control system 200 are configured to receive an acknowledgment including a congestion window and operate according to the congestion window in the acknowledgment. In one non-limiting embodiment, the (multiple) senders 204 can be further configured to adjust the congestion window based on events that the receiver 202 may not easily detect in the embodiment (such as packet loss of the first or last packet transmitted, etc.), where, for example, when detecting packet loss of the first or last packet transmitted, the congestion window of the corresponding sender 204 is adjusted downward.

[0045] At the receiving end 202, a (or multiple) delay calculator 206 can be provided for each of one or more sending ends 204 from which the receiving end 202 receives packets. Each of the (multiple) delay calculators 206 is a module that can include software, hardware, a combination thereof, etc., and is provided as part of the receiving end 202. Each of the (multiple) delay calculators 206 is configured to determine the one-way delay of a packet received from the corresponding sending end 204 associated with the delay calculator. The one-way delay value can be calculated at the (multiple) delay calculators 206 by subtracting the time when the packet is received at the receiving end 202 ("T receiving end") from the time when the packet is sent from the corresponding sending end 204 ("T sending end"). T sending end can be determined based on the received packet, for example, by a timestamp attached to the packet when it is sent by the sending end 204. In some embodiments, the determination of T sending end can be performed without further communication with the sending end 204 after the packet is received. In some embodiments, a constant value can also be added, for example, to avoid a negative delay value. Accordingly, in a non-limiting embodiment, the formula for determining the one-way delay can be: (T receiving end - T sending end) + C. The one-way delay value determined at the delay calculator 206 can be monitored over time, for example, to determine the rate of change, minimum value, and maximum value within a predetermined time window, to determine the one-way delay value smoothed over time, etc.

[0046] (Multiple) congestion window calculators 208 are configured to determine a congestion window based on received packets and one-way delays determined by (multiple) corresponding delay calculators 208. Each of the (multiple) congestion window calculators 208 is a module that may include software, hardware, combinations thereof, etc., and is provided as part of the receiver 202. A congestion window calculator 208 may be provided at the receiver 202 for each sender 204 from which packets are received. The (multiple) congestion window calculators 208 may use any suitable method to determine the congestion window based on information available at the receiver 202 based on received packets. In an embodiment, each of the (multiple) congestion window calculators 208 may determine the congestion window of a corresponding sender 202 based on one or more of packet loss detection, explicit congestion notification (ECN) included in received packets, and / or one-way delay. In an embodiment, one or more of the instantaneous one-way delay values, smoothed values of the one-way delay, and / or minimum or maximum values of the one-way delay within a predetermined time window may be compared with a target value or threshold to determine whether to reduce the congestion window based on the one-way delay. In an embodiment, when determining the congestion window, the congestion window calculator may prioritize packet loss, ECN inclusion, and one-way delay in descending order. In an embodiment, the (multiple) congestion window calculators 208 may reduce the congestion window by a first reduction when packet loss is detected, by a second reduction when ECN is detected, and by a third reduction when the one-way delay exceeds a threshold. In an embodiment, when packet loss is detected, the reduction of the congestion window may be a multiplicative reduction, such as halving the congestion window when packet loss is detected at the receiver 202. In an embodiment, when ECN is detected, the reduction of the congestion window may be based on the portion of packets including ECN received within a defined time window. In an embodiment, when the one-way delay exceeds a threshold, the reduction of the congestion window may be based on the extent to which the one-way delay exceeds the threshold. In an embodiment, when no packet loss is detected, when no ECN is received, and the one-way delay is below the threshold, the congestion window may be incremented upward. In an embodiment, the upward increment of the congestion window may be based on the number of acknowledgments and the current value of the congestion window. A non-limiting example of a method for determining a congestion window is described below and shown in Figure 3 and shown in Figure 3 . The (multiple) congestion window calculators 208 may use the method described below and shown in

[0047] (Multiple) flow control and fairness modules 210 are configured to adjust the determined congestion window values to implement flow control and / or ensure fairness among multiple senders 204 that provide data packets to the receiver 202. The (multiple) flow control and fairness modules 210 are each modules that may include software, hardware, combinations thereof, etc., and are provided as part of the receiver 202. In an embodiment, a flow control and fairness module 210 is provided for each sender 204 that sends packets to the receiver 202. In an embodiment, the multiple flow control and fairness modules 210 communicate with each other to adjust the determined congestion window values to implement flow control and / or ensure fairness. In an embodiment, one flow control and fairness module may be provided to adjust the congestion window for each of one or more congestion window calculators 208 and output each corresponding adjusted congestion window to a corresponding congestion window token generator 212. The flow control and fairness module may adjust the congestion window of each sender 204 based on the corresponding bandwidth consumption of each sender 204. In an embodiment, different senders 204 may receive different priorities or bandwidth allocations, which may affect the adjustment of the congestion window by the (multiple) flow control and fairness modules 210.

[0048] (Multiple) congestion window token generators 212 are configured to generate acknowledgment tokens for packets received from the senders 204. The acknowledgment tokens may include updated values of the congestion window to be provided to the senders 204. The updated value of the congestion window may be the value determined by the corresponding congestion window calculator 208 and optionally further adjusted by the (multiple) flow control and fairness modules 210. The acknowledgment tokens may be sent from the receiver 202 to the corresponding senders 204 of the packets to acknowledge receipt of the packets and provide the congestion window for the corresponding senders 204 to use when sending packets to the receiver 202. The receiver 202 may send the acknowledgment tokens including the values of the congestion window to the corresponding senders 204 through any suitable data connection (e.g., the connection used by the senders 204 to provide packets to the receiver 202).

[0049] Figure 3A flowchart of a method according to an embodiment is shown. Method 300 includes determining at 302 whether packet loss has occurred at a receiving end of a network. Method 300 further includes determining at 304 whether a packet with a congestion signal has been received at the receiving end of the network. The method further includes determining a delay at 306 and comparing the delay with a target delay at 308. When it is determined at 302 that packet loss has occurred, at 304 that a packet with a congestion signal has been received, and / or at 308 that the delay exceeds the target delay, the congestion window can be adjusted downward at 310. When it is determined at 302 that no packet loss has occurred, at 304 that no packet with a congestion signal has been received, and at 308 that the delay is less than or equal to the target delay, the congestion window can be adjusted upward at 312. The adjusted congestion window can be provided to the sending end at 314. In an embodiment, method 300 can optionally further include further adjusting the congestion window at 316 based on flow control and / or fairness. Optionally, at 318, the sending end can perform packet loss replenishment detection. When the sending end detects packet loss in the packet loss replenishment detection at 318, the congestion window can be adjusted downward at 320.

[0050] Method 300 provides congestion and flow control for a network from the perspective of the packet receiving end. In an embodiment, method 300 is a method for updating a congestion window for a specific sending end that sends data packets to a receiving end. When a packet of a specific data stream from a specific sending end is received at the receiving end, method 300 can be performed for the data stream. In Figure 3 the illustrated embodiment, method 300 controls congestion and flow control based on packet loss, reception of a congestion signal, and delay in a priority order when receiving a sent packet. In the algorithm of an embodiment for performing method 300, a series of "else if" statements can be used according to the factors for determining the congestion window and their priorities. It should be understood that in alternative embodiments, one or more of the detection of packet loss, congestion signal, and / or delay can be omitted from method 300 when updating the congestion window. It should be understood that in alternative embodiments, other suitable network congestion metrics can also be used to replace or supplement the detection of packet loss, congestion signal, and / or delay. It should be understood that in alternative embodiments, the priorities can vary in some methods. For example, when determining an update to the congestion window, reception of a congestion signal or delay can be given priority over packet loss. In some embodiments, method 300 can be entirely performed at a network receiving end node that receives data packets from one or more sending end nodes of the network. Optionally, method 300 can further include actions performed as a sending end node of the network, such as performing packet loss replenishment detection at 318 and performing a corresponding adjustment of the congestion window at 320.

[0051] At 302, the occurrence of packet loss is determined at the receiving end. The determination of packet loss at 302 can be performed by any suitable packet loss detection means that can be implemented at the receiving end, such as determining the time when certain expected data packets have not been received within a predetermined time window. The receiving end can identify the expected packets based on other received packets of the data stream. Packet loss can include packets lost in the network or packets discarded from the queue of a host (such as a terminal host). When packet loss is determined at 302, method 300 can continue to adjust the congestion window downward at 310. When it is determined at 302 that no packet loss has occurred, method 300 can instead continue to determine at 304 whether a congestion signal has been received. In an embodiment, when any packet loss is detected, packet loss is determined at 302. In an embodiment, when the packet loss exceeds a threshold, packet loss is determined at 302.

[0052] The presence of a congestion signal can be determined at 304. The determination of the presence of a congestion signal can be performed at 304 by reading or otherwise analyzing the packets of the data stream received from the sending end. Under congestion conditions, the sending end can append a congestion signal to the packets being sent. The congestion signal can be any suitable signal for expressing that congestion is occurring, and a non-limiting example is an explicit congestion notification (ECN) provided by the sending end. In an embodiment, the congestion signals of multiple packets from the data stream can be tracked, such that the determination of the presence of a congestion signal also includes the ratio of the number of packets with congestion signals to the total number of packets of the data stream. When it is determined at 304 that a congestion signal is present, method 300 can continue to adjust the congestion window downward at 310. When it is determined at 304 that no congestion signal is present, method 300 can continue to determine the delay at 306 or compare the delays at 308.

[0053] The delay is determined at 306. After determining at 304 that no congestion signal is present, the delay can be determined at 306, or the delay can be determined for each packet without considering the determination of the congestion signal at 304. The delay can be determined at 306 by any suitable method that can be performed by the receiving end node to characterize the delay when receiving a packet. The delay can be, for example, a one-way delay. The delay can be caused by, for example, as described above and Figure 2It is detected by the delay calculator 206 shown. In an embodiment, the delay may be a one-way delay determined according to the formula (T receiver - T sender) + C as described above. In an embodiment, the delay may be determined at 306 based on the time-varying one-way delay, for example, the delay may be defined as the minimum value, maximum value, average value, or smoothed value of the one-way delay based on the one-way delays of multiple packets received within a predetermined time window. At 308, the delay determined at 306 may be compared with a target delay or a threshold delay. The target delay or threshold delay at 308 may be, for example, a desired level of delay, or a delay threshold indicating a congestion level that requires adjustment of the congestion window. When it is found in the comparison at 308 that the delay determined at 306 exceeds the target delay or threshold delay, method 300 may continue to adjust the congestion window downward at 310. When it is found in the comparison at 308 that the delay determined at 306 is at or below the target delay or threshold delay, method 300 may continue to adjust the congestion window upward at 312. In an alternative embodiment, the adjustment of the congestion window may further include keeping the congestion window at the current value under certain conditions, for example, when the delay is within a range at or near the target delay value or threshold delay value (e.g., within a predefined range defined around the target delay value or threshold delay value).

[0054] When packet loss is determined at 302, a congestion signal is determined at 304, or it is found at 308 that the delay exceeds the target delay or threshold delay, the congestion window may be adjusted downward at 310. Adjusting the congestion window downward at 310 instructs the sender to reduce the number of packets that can be sent before requesting an acknowledgment for previously sent packets, thereby reducing the sending rate of the sender. The congestion window may be adjusted downward at 310 by any suitable reduction scheme (such as multiplicative decrease, subtracting from the congestion window value, etc.).

[0055] In an embodiment, the congestion window may be adjusted downward at 310 based on a specific basis for advancing to 310. For example, a first downward adjustment may be performed when packet loss is determined at 302, a second different downward adjustment may be performed when a congestion signal is determined at 304, and a third different downward adjustment may be performed when it is determined at 308 that the delay exceeds the target delay or threshold delay.

[0056] In an embodiment, when packet loss is determined at 302, the downward adjustment of the congestion window at 310 may be a multiplicative decrease of the congestion window, for example, by dividing the congestion window by a suitable constant for responding to packet loss. In an embodiment, the constant may be 2, so that when packet loss is determined at 302, the congestion window is halved in the downward adjustment at 310.

[0057] In an embodiment, when a congestion signal is determined at 304, the downward adjustment of the congestion window at 310 can be based on the ratio of the number of packets including the congestion signal to the total number of packets. In an embodiment, the total number of packets is the total number of packets of the data stream. In an embodiment, the total number of packets used to determine the ratio is the total number of packets received within a predetermined time window. As a non-limiting example, when the congestion window is downward adjusted at 310 based on the congestion signal determined at 304, the congestion window can be adjusted according to the following formula: CWND adjusted = CWND current * (1 - [packet signal / total packets]), where CWND adjusted is the adjusted congestion window, CWND current is the currently used congestion window, and packet signal / total packets is the ratio of the number of packets including the congestion signal to the total number of packets.

[0058] In an embodiment, when it is determined at 308 that the delay exceeds the target delay or the threshold delay, the downward adjustment of the congestion window at 310 can be based on the values of the current delay and the target delay or the threshold delay. In an embodiment, an adjustment factor can be calculated based on the values of the current delay and the target delay or the threshold delay, and the current congestion window can be multiplied by the adjustment factor to determine the adjusted congestion window. In an embodiment, the adjustment factor can be based on the ratio of the current delay minus the target delay or the threshold delay. In an embodiment, a maximum reduction can also be provided to limit the extent to which the congestion window can be downward adjusted at 310 in response to the delay exceeding the target delay or the threshold delay at 308. In a non-limiting example, the congestion window can be determined according to the following formula: CWND adjusted = CWND current * max([1 - B * {current delay - target delay} / current delay], maximum reduction), where current delay is the current value of the delay determined at 306, target delay is the target delay value or the threshold delay value, and maximum reduction is the predetermined maximum reduction value of the congestion window in response to the delay exceeding the target delay or the threshold delay.

[0059] For example, when it is determined at 302 that there is no packet loss, at 304 that there is no congestion signal, and at 308 that the delay does not exceed the target delay or the threshold delay, an upward adjustment of the congestion window can be performed at 312. The upward adjustment performed at 312 can be, for example, a summative increase of the congestion window, such as by incrementing the congestion window. The congestion window can be incremented by a certain amount based on the number of packet acknowledgments received by the sender. As a non-limiting example, the upward adjustment of the congestion window at 312 can be determined according to the following formula: CWND adjusted = CWND current + A * (acknowledgment / CWND current), where A is a predetermined constant, and acknowledgment is the number of packet acknowledgments received by the sender.

[0060] The congestion window can be provided to the sender at 314. In an embodiment, when the congestion window has been adjusted downward at 310 or upward at 312, the congestion window is provided to the sender at 314. In an embodiment, even if there is no adjustment to the congestion window, the congestion window is provided to the sender at 314. The congestion window can be provided to the sender as part of the acknowledgment of the receipt of the packet (such as a token included in the acknowledgment, etc.). At 314, the acknowledgment including the congestion window can be provided to the sender through any suitable communication of the acknowledgment. The sender can then control the transmission to the receiver according to the congestion window at 314, so as to adjust the transmission rate of the sender based on the congestion window determined at the receiver.

[0061] Optionally, at 316, the congestion window can be further adjusted based on flow control and / or fairness. The further adjustment of the congestion window at 316 (if performed) can be executed before the congestion window is provided to the sender at 314. The adjustment of the congestion window at 316 based on flow control and / or fairness can be based on the available bandwidth and the corresponding bandwidth allocated for a specific data stream. In an embodiment, when allocating bandwidth among data streams from various senders, the adjustment of the congestion window at 316 treats each sender equally. In an embodiment, different senders can have different bandwidth allocations, priorities of bandwidth allocations, etc., and the adjustment of the congestion window at 316 based on flow control and / or fairness can be based on such allocations, priorities, etc. In a non-limiting example, the average bandwidth can be determined by dividing the current total bandwidth capacity by the total number of active data streams. In this non-limiting example, when the congestion window causes the data stream to be at or below the average bandwidth, the congestion window of this data stream can be used without further adjustment. The bandwidth used by the streams at or below the average bandwidth can be subtracted from the current total bandwidth to determine the adjusted total bandwidth, and the congestion window of the data streams using more than the average bandwidth can be adjusted so that the adjusted total bandwidth is evenly distributed to each of the data streams using more than the average bandwidth.

[0062] In an embodiment, the sender can further contribute to congestion and flow control in method 300. At 318, the sender can perform lost packet replenishment detection. Lost packet replenishment detection can be for packets for which the receiver may not observe packet loss, such as the first packet and / or the last packet of a data stream. Packet loss detection can be based on any suitable sender-side packet loss detection, such as timing out in the absence of receiving an acknowledgment from the receiver. When the lost packet replenishment detection at 318 indicates packet loss that the receiver may not observe, the sender can perform a local downward adjustment of the congestion window at 320. The local downward adjustment at 320 can be according to any suitable scheme for responding to packet loss detected by a sensor. In an embodiment, the congestion window downward adjustment at 320 can be similar to or based on the same adjustment made in response to packet loss detection at 310. As a non-limiting example, when packet loss is detected in the lost packet replenishment detection at 318, the congestion window at the sender can be divided by a predetermined constant value. In an embodiment, the predetermined constant value can be 2, such that the congestion window is halved when packet loss is detected at 318.

[0063] It should be understood that the disclosed and other solutions, examples, embodiments, modules, and functional operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus can include code that creates an execution environment for the computer programs being discussed, e.g., code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0064] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), stored in a single file dedicated to the program being discussed, or stored in multiple co-operating files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0065] The processes and logical flows described in this specification can be performed by one or more programmable processors that execute one or more computer programs to perform functions by operating on input data and generating output. These processes and logical flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., a field programmable gate array, an application specific integrated circuit, etc.

[0066] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, e.g., magnetic disks, magneto-optical disks, or optical disks, or operatively coupled to one or more mass storage devices for receiving data therefrom or transferring data thereto, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and storage devices, including by way of example semiconductor memory devices, such as erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and compact disc read only memory (CD-ROM) and digital video disc (DVD) disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0067] It should be understood that various features, variations, and multiple different embodiments have been shown and described in detail. What is sometimes described in terms of specific embodiments in this application is for illustrative purposes only and is not intended to limit or imply that only one specific embodiment or multiple specific embodiments are contemplated. It should be understood that the present disclosure is not limited to any single specific embodiment or enumerated variation. Those skilled in the art will conceive of many modifications, variations, and other embodiments, and these modifications, variations, and other embodiments are intended to and in fact are covered by the present disclosure. Indeed, the scope of the present disclosure should be determined by a proper legal interpretation and construction (including equivalents) of the present disclosure as understood by those skilled in the art based on the complete disclosure presented at the time of filing.

[0068] Aspect:

[0069] It should be understood that any one of aspects 1 to 10 can be combined with any one of aspects 11 to 20, 21 to 22, 23, 24, or 25. It should be understood that any one of aspects 11 to 20 can be combined with any one of aspects 21 to 22, 23, 24, or 25. It should be understood that any one of aspects 21 to 22 can be combined with any one of aspects 23, 24, or 25. It should be understood that any one of aspects 23, 24, and 25 can be combined with each other.

[0070] Aspect 1. A computer network, comprising:

[0071] A receiving end node configured to receive data packets from one or more sending end nodes, the receiving end node being configured to:

[0072] Determine network congestion;

[0073] Based on the determination of network congestion, determine the congestion window of the one or more sending end nodes; and

[0074] Transmit the congestion window to the one or more sending end nodes.

[0075] Aspect 2. The computer network according to aspect 1, wherein the sending end node is configured to determine network congestion by:

[0076] Detect packet loss in the data packets received from the one or more sending end nodes;

[0077] Detect explicit congestion notification (ECN) in the data packets received from the one or more sending end nodes; and

[0078] Determine the one-way delay of the data packets received from the one or more sending end nodes.

[0079] Aspect 3. The computer network according to Aspect 1 or Aspect 2 further includes the one or more sending end nodes, and wherein each of the one or more sending end nodes is configured to receive the congestion window of the sending end node from the receiving end node, and control the sending of packets from the sending end node based on the congestion window.

[0080] Aspect 4. The computer network according to Aspect 3, wherein at least some of the one or more sending end nodes are configured to detect packet loss of the first packet and the last packet in the data packets sent from the sending end node to the receiving end node, and reduce the congestion window when detecting the packet loss of the first packet and the last packet.

[0081] Aspect 5. The computer network according to any one of Aspects 2 to 4, wherein the receiving end node is configured to determine the one-way delay by determining the difference between the time at the receiving end and the timestamps when multiple packets in the data packets are sent from the one or more sending end nodes.

[0082] Aspect 6. The computer network according to any one of Aspects 2 to 5, wherein the receiving end node is configured such that when the receiving end node detects the packet loss, the receiving end node determines to reduce the congestion window.

[0083] Aspect 7. The computer network according to any one of Aspects 2 to 6, wherein the receiving end node is configured such that when the receiving end node does not detect packet loss and the receiving end node detects the ECN, the receiving end node determines to reduce the congestion window.

[0084] Aspect 8. The computer network according to any one of Aspects 2 to 7, wherein the receiving end node is configured such that when the receiving end node does not detect packet loss and the receiving end node does not detect the ECN, compare the one-way delay with the target one-way delay, and when the one-way delay exceeds the target one-way delay, the receiving end node determines to reduce the congestion window.

[0085] Aspect 9. The computer network according to any one of Aspects 1 to 8, wherein the receiving end node is further configured to adjust the congestion window of the corresponding sending end node based on a comparison between the bandwidth of the flow from the corresponding sending end node among the one or more sending end nodes and the average bandwidth of the flows from the one or more sending end nodes.

[0086] Aspect 10. The computer network according to Aspect 9, wherein different sending end nodes among the one or more sending end nodes have different priorities, and the receiving end node is configured to adjust the congestion window based on the priority of the corresponding sending end node.

[0087] Aspect 11. A method for controlling traffic in a computer network, the method comprising:

[0088] At a receiving end node configured to receive data packets from one or more sending end nodes,

[0089] Determine network congestion;

[0090] At the receiving end node, determine the congestion window of the one or more sending end nodes based on the determination of the network congestion; and

[0091] Transmit the congestion window from the receiving end node to the one or more sending end nodes.

[0092] Aspect 12. The method according to aspect 11, wherein the determination of the network congestion includes at least one of the following operations:

[0093] At the receiving end node, detect packet loss in the data packets received from the one or more sending end nodes;

[0094] At the receiving end node, detect explicit congestion notification (ECN) in the data packets received from the one or more sending end nodes; or

[0095] At the receiving end node, determine the one-way delay of the data packets received from the one or more sending end nodes.

[0096] Aspect 13. The method according to aspect 11 or aspect 12, further comprising: at the one or more sending end nodes, receive the congestion window of the sending end node from the receiving end node, and operate the sending end node to send packets to the receiving end node based on the congestion window.

[0097] Aspect 14. The method according to aspect 12, further comprising: at the one or more sending end nodes, detect packet loss of the first packet and the last packet in the data packets sent from the sending end node to the receiving end node, and reduce the congestion window when the packet loss of the first packet and the last packet is detected.

[0098] Aspect 15. The method according to any one of aspects 12 to 14, wherein determining the one-way delay includes determining the difference between the time at the receiving end and the timestamps when multiple packets in the data packets are sent from the one or more sending end nodes.

[0099] Aspect 16. The method according to any one of aspects 12 to 15, wherein when the receiving end node detects the packet loss, the receiving end node determines to reduce the congestion window.

[0100] Aspect 17. The method according to any one of Aspects 12 to 16, wherein when the receiving end node does not detect packet loss and the receiving end node detects the ECN, the receiving end node determines to reduce the congestion window.

[0101] Aspect 18. The method according to any one of Aspects 12 to 17, wherein when the receiving end node does not detect packet loss and the receiving end node does not detect the ECN, the one-way delay is compared with a target one-way delay, and when the one-way delay exceeds the target one-way delay, the receiving end node determines to reduce the congestion window.

[0102] Aspect 19. The method according to any one of Aspects 11 to 18, further comprising adjusting the congestion window of the corresponding sending end node based on a comparison of the bandwidth of the flow from the corresponding sending end node among the one or more sending end nodes with the average bandwidth of the flows from the one or more sending end nodes.

[0103] Aspect 20. The method according to any one of Aspects 11 to 19, wherein different sending end nodes among the one or more sending end nodes have different priorities, and thus the congestion window is adjusted based on the priority of the corresponding sending end node.

[0104] Aspect 21. A non-transitory computer-readable medium having computer-executable instructions stored thereon, which when executed cause one or more processors of a receiving end node of a computer network to perform operations including:

[0105] Detecting explicit congestion notification (ECN) in data packets received from the one or more sending end nodes;

[0106] Determining the one-way delay of data packets received from the one or more sending end nodes;

[0107] Determining the congestion window of the one or more sending end nodes based on at least one of packet loss detection, ECN detection, or one-way delay; and

[0108] Transmitting the congestion window from the receiving end node to the one or more sending end nodes.

[0109] Aspect 22. The non-transitory computer-readable medium according to Aspect 21, wherein determining the congestion window includes:

[0110] When the receiving end node detects the packet loss, determining to reduce the congestion window;

[0111] When the receiving end node does not detect packet loss and the receiving end node detects the ECN, determining to reduce the congestion window; and

[0112] When the receiving end node does not detect packet loss and does not detect the ECN, compare the one-way delay with the target one-way delay, and when the one-way delay exceeds the target one-way delay, determine to reduce the congestion window.

[0113] Aspect 23. A computer network, comprising:

[0114] A receiving end node configured to receive data packets from one or more sending end nodes, the receiving end node being configured to:

[0115] Dynamically adjust the congestion window to be sent to the one or more sending end nodes based on the detection of one of packet loss, congestion signal, and packet delay signal from the one or more sending end nodes; and

[0116] Transmit the congestion window to the one or more sending end nodes.

[0117] Aspect 24. A method for controlling traffic in a computer network, the method comprising:

[0118] At a receiving end node configured to receive data packets from one or more sending end nodes, dynamically adjust the congestion window to be sent to the one or more sending end nodes based on the detection of one of packet loss, congestion signal, and packet delay signal from the one or more sending end nodes; and

[0119] Transmit the congestion window from the receiving end node to the one or more sending end nodes.

[0120] Aspect 25. A non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed, cause one or more processors of a receiving end node of a computer network to perform operations including the following:

[0121] Dynamically adjust the congestion window to be sent to the one or more sending end nodes based on the detection of one of packet loss, congestion signal, and packet delay signal from the one or more sending end nodes; and

[0122] Transmit the congestion window from the receiving end node to the one or more sending end nodes.

[0123] The examples disclosed in this application should be considered illustrative rather than restrictive in all respects. The scope of the present invention is indicated by the appended claims rather than the foregoing description; and all changes within the equivalent meaning and scope of the claims are intended to be included therein.

Claims

1. A computer network comprising: a receiving end node, the receiving end node being configured to receive data packets from one or more sending end nodes, the receiving end node being configured to: determine network congestion; determining, at the receiving end node, a congestion window for the one or more sending end nodes based on a determination of network congestion at the receiving end node; and The congestion window is transmitted to the one or more sending end nodes.

2. The computer network according to claim 1, wherein: The sending node is configured to determine network congestion by at least one of the following operations: detecting packet loss in the data packets received from the one or more sending end nodes; detecting an explicit congestion notification, ECN, in said data packets received from said one or more sending end nodes; or A one-way delay of the data packet received from the one or more sending end nodes is determined.

3. The computer network of claim 1 , further comprising the one or more sending end nodes, and wherein: Each of the one or more transmitting end nodes is configured to receive the congestion window of the transmitting end node from the receiving end node, and control sending of packets from the transmitting end node based on the congestion window.

4. The computer network according to claim 3, wherein: At least some of the one or more transmitting end nodes are configured to detect packet loss of a first packet and a last packet of the data packets sent from the transmitting end node to the receiving end node, and to reduce the congestion window upon detecting the packet loss of the first packet and the last packet.

5. The computer network according to claim 2, wherein: The receiving end node is configured to determine a one-way delay by determining a difference between a time at the receiving end and a timestamp when a plurality of packets in the data packet were sent from the one or more sending end nodes.

6. The computer network according to claim 2, wherein: The receiving end node is configured such that when the receiving end node detects the packet loss, the receiving end node determines to reduce the congestion window.

7. The computer network according to claim 2, wherein: The receiving end node is configured such that when the receiving end node detects no packet loss and the receiving end node detects the ECN, the receiving end node determines to reduce the congestion window.

8. The computer network according to claim 2, wherein: The receiving end node is configured to compare the one-way delay with a target one-way delay when the receiving end node does not detect packet loss and the receiving end node does not detect the ECN, and when the one-way delay exceeds the target one-way delay, the receiving end node determines to reduce the congestion window.

9. The computer network of claim 1, wherein: The receiving end node is further configured to adjust a congestion window of a corresponding one of the one or more sending end nodes based on a comparison of a bandwidth of flows from the corresponding sending end node and an average bandwidth of flows from the one or more sending end nodes.

10. The computer network according to claim 9, wherein: Different ones of the one or more sender nodes have different priorities, and the receiver node is configured to adjust the congestion window based on the priorities of the corresponding sender nodes.

11. A method for controlling traffic in a computer network, the method comprising: At a receiving end node configured to receive packets from one or more sending end nodes, determining network congestion; At the receiving end node, determining a congestion window of the one or more sending end nodes based on the determination of the network congestion; as well as The congestion window is transmitted from the receiving end node to the one or more sending end nodes.

12. The method according to claim 11, wherein: The determination of the network congestion includes at least one of the following operations: At the receiving end node, detecting packet loss in the data packets received from the one or more sending end nodes; detecting, at the receiving end node, an explicit congestion notification (ECN) in the data packets received from the one or more sending end nodes; or At the receiving end node, a one-way delay of the data packet received from the one or more sending end nodes is determined.

13. The method of claim 11, further comprising, at the one or more sending end nodes, receiving the congestion window of the sending end node from the receiving end node, and operating the sending end node to send packets to the receiving end node based on the congestion window.

14. The method of claim 13, further comprising detecting, at the one or more sending end nodes, packet loss of a first packet and a last packet of the data packets sent from the sending end node to the receiving end node, and reducing the congestion window when the packet loss of the first packet and the last packet is detected.

15. The method according to claim 12, wherein: Determining the one-way delay includes determining a difference between a time at the receiving end and a timestamp when a plurality of packets in the data packet were sent from the one or more transmitting end nodes.

16. The method according to claim 12, wherein: When the receiving end node detects the packet loss, the receiving end node determines to reduce the congestion window.

17. The method according to claim 12, wherein: When the receiving end node does not detect packet loss and the receiving end node detects the ECN, the receiving end node determines to reduce the congestion window.

18. The method according to claim 12, wherein: When the receiving end node does not detect packet loss and the receiving end node does not detect the ECN, the one-way delay is compared with a target one-way delay, and when the one-way delay exceeds the target one-way delay, the receiving end node determines to reduce the congestion window.

19. The method of claim 11, further comprising adjusting a congestion window of a corresponding sender node among the one or more sender nodes based on a comparison of a bandwidth of a flow from the corresponding sender node with an average bandwidth of flows from the one or more sender nodes.

20. The method according to claim 11, wherein: Different sender nodes among the one or more sender nodes have different priorities, so that the congestion window is adjusted based on the priorities of the corresponding sender nodes.

21. A non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed, cause one or more processors of a receiving node of a computer network to perform operations comprising: detecting an explicit congestion notification, ECN, in said data packets received from said one or more sending end nodes; determining a one-way delay of the data packet received from the one or more sending end nodes; Determining a congestion window of the one or more sending end nodes based on at least one of packet loss detection, ECN detection, or one-way delay; as well as The congestion window is transmitted from the receiving end node to the one or more sending end nodes.

Images