Method and system for controlling network flow based on packet loss reason

Abstract

The invention provides a method and a system for controlling network flow based on packet loss reasons. The method comprises: detecting packet loss of data packets in network traffic received from one or more sender nodes; determining a cause of packet loss; and controlling network traffic in the computer network based on the determined cause of packet loss. The reasons of packet loss are different reasons of link congestion or packet loss.

Description

Technical Field

[0001] Embodiments described herein generally relate to controlling network traffic in a computer network. More specifically, embodiments described herein relate to methods, programs, devices, and systems for controlling network traffic based on packet loss, by which network traffic is controlled based on the cause of the packet loss. Background Art

[0002] In computer networking, data centers are provided for various services such as search, cloud computing, social networking, shopping, big data analysis, gaming, communication, etc. As the data transfer rate, utilization, and scale in a computer network increase, it becomes increasingly important to monitor the underlying network structure and protocols to maximize the transmission performance in the computer network to enhance the user experience, e.g., controlling network traffic to minimize latency.

[0003] For example, the Transmission Control Protocol (TCP) can be used to control network traffic because TCP can be designed, programmed, or otherwise configured to carry much higher network traffic on the Internet than any other transport layer protocol. It is well known that Additive Increase / Multiplicative Decrease (AIMD) can be used as a control algorithm to adjust the TCP network traffic flow rate for congestion control, e.g., by adjusting the Maximum Segment Size or Packet Size (MSS) (e.g., the maximum amount of data that TCP can receive in a single segment in the congestion window (CWND) at a sender node, end node, and / or receiver node). The basic idea of congestion control is that the sender transmits TCP packets on the network, and then the system or network reacts to observable events to increase or decrease the transmission rate. For example, if the network is over-utilized, the transmission rate is decreased, e.g., by reducing the size of the CWND; or if the network is under-utilized, the transmission rate is increased, e.g., by increasing the size of the CWND.

[0004] There are various indicators of congestion, e.g., packet loss, which can signal that the network is over-utilized. When the sender transmits TCP packets at a flow rate faster than the capacity of the bottleneck device (e.g., the link, end node, destination device, etc. with the minimum allocated bandwidth in the flow path), the bottleneck device puts the TCP packets into a buffer. As the sender continues to transmit packets at a rate faster than the packets leave the buffer, the buffer will fill up with packets until eventually there is no capacity left for additional packets. When the buffer is full, the bottleneck device may discard new packets when they arrive, e.g., packet loss. The sender can be notified of packet loss when it does not receive an acknowledgement (ACK), and then the sender can reduce its transmission rate, e.g., by reducing the size of the CWND. Summary of the Invention

[0005] The features in the embodiments disclosed herein can provide methods, programs, devices, and systems for improving computer network performance by making different responses to packet losses caused by different network congestion events. In some embodiments, the methods, devices, and systems can be designed, programmed, or otherwise configured to distinguish or determine various causes of packet loss and control network traffic differently based on one or more of the various causes of packet loss. In some embodiments, the methods, programs, devices, and systems can use network congestion signals (such as, explicit congestion notification (ECN), round-trip time (RTT), or in-band network telemetry (INT)) to distinguish or determine whether a packet loss is due to link congestion or due to different causes of packet loss (such as physical layer problems or hardware errors, cyclic redundancy check (CRC) failures, software errors, etc.). Thus, by having methods, programs, devices, and systems that respond to packet losses based on the cause of the packet loss, computer network performance (and quality of service) can be improved. For example, when a packet loss is due to a cause other than link congestion, reducing the congestion window (CWND) may actually have an adverse effect on computer network performance. Therefore, methods, programs, devices, and systems as discussed herein can be provided such that when it is determined that the cause of the packet loss is not due to link congestion, network traffic can be maintained, but network traffic is reduced only when it is primarily determined that the cause of the packet loss is due to link congestion (e.g., only when the cause of the packet loss is due to link congestion). The methods, programs, devices, and systems can also be used to track physical layer problems along a path or link, which can be used to alert network operators to replace any problematic devices, links, etc.

[0006] In one example embodiment, a method of controlling network traffic in a computer network using a communication protocol is provided. The method includes: detecting packet loss of data packets in network traffic received from one or more sender nodes; determining the cause of the packet loss; and controlling network traffic in the computer network based on the determined cause of the packet loss. The cause of the packet loss is due to link congestion or different causes of packet loss.

[0007] In another embodiment, a congestion controller in a computer network using a communication protocol is provided. The congestion controller includes: a processor configured to execute instructions, wherein when the instructions are executed, cause the processor to: detect packet loss of data packets in network traffic received from one or more sender nodes; determine the cause of the packet loss; and control network traffic in the computer network based on the determined cause of the packet loss. The cause of the packet loss is due to link congestion or different causes of packet loss.

[0008] In yet another embodiment, a non-transitory computer-readable medium is provided, having computer-executable instructions stored thereon. When executed, the computer-executable instructions cause one or more processors of an end node of a computer network using a communication protocol to perform operations, the operations including: detecting packet loss of data packets in network traffic received from one or more sender nodes; determining the cause of the packet loss; and controlling network traffic in the computer network based on the determined cause of the packet loss. The cause of the packet loss is due to link congestion or different reasons for packet loss. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0010] Figure 1 is a schematic diagram of an example computer networking system arranged according to at least some embodiments described herein for controlling network traffic.

[0011] Figure 2 is a schematic diagram of an example network arranged according to at least some embodiments described herein for managing network traffic.

[0012] Figure 3 is a schematic diagram of an AIMD control algorithm arranged according to at least some embodiments described herein.

[0013] Figure 4 is a schematic diagram of an example comparison of an existing congestion control algorithm and a congestion control algorithm arranged according to at least some embodiments described herein.

[0014] Figure 5 is a flowchart showing an example processing procedure for controlling network traffic according to at least some embodiments described herein.

[0015] Figure 6 is a schematic structural diagram of an example computer system suitable for implementing a device arranged according to at least some embodiments described herein. DETAILED DESCRIPTION

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

[0017] It should be understood that the disclosed embodiments are merely examples of the present disclosure, which may be embodied in various forms. Well-known functions or constructions are not described in detail to avoid obscuring the present disclosure with unnecessary details. Thus, 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 one of ordinary skill in the art to employ the present disclosure in virtually any appropriately detailed structure.

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

[0019] 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 may be performed in any order and are not limited to the order presented in the claim. Further, no element is essential to the practice of the present disclosure unless specifically described herein as "critical" or "essential".

[0020] As used herein, "computer networking" or "computer network" may be a technical term that refers to interconnected computing devices that can exchange data and share resources with each other. It should be understood that networking devices may transmit or receive information via wired or wireless technologies using communication protocols (e.g., rules of the system, etc.).

[0021] As used herein, "packet", "data packet", "network packet", or "network data packet" in computer networking can be a technical term referring to a formatted data unit carried by a computer networking system. It should be understood that a packet can include control information and user data. User data can refer to "payload". Control information can provide information for delivering the payload (e.g., source network address and destination network address, error detection code, sequencing information, etc.). It should also be understood that control information can generally be stored in the packet header and / or trailer. Further, it should be understood that control information can include metadata. Metadata in computer networking can refer to descriptive information about user data, or "data about data". Metadata can carry various characteristics related to the structure and packets of a communication protocol.

[0022] As used herein, "traffic flow", "packet flow", "network traffic flow", "network traffic", or "network flow" in computer networking can refer to the amount or sequence of packets from a source computer or device to a destination computer or device (which can be another host, multicast group, or broadcast domain including routers and / or switches for transmitting (and / or receiving) packets). It should be understood that a traffic flow can include all packets in a particular transmission connection and / or media stream, and can include a set of packets passing through an observation point in a network during a particular time interval.

[0023] As used herein, "congestion window" or "CWND" in computer networking can refer to a variable that can be controlled to limit the amount of data that a control protocol (e.g., TCP) can send into the network before receiving an ACK. That is, CWND is one of the factors determining the number of bytes that can be sent by a sender (e.g., a sender node), and CWND can use this factor to prevent the link between the sender and the receiver (e.g., an end node) from being overloaded due to excessive traffic. When a connection is established, CWND can be set based on the amount of network traffic allowed by the receiver or host (e.g., an end node) or (one or more) intermediate devices (e.g., links, routers, switches, etc.). CWND can be adjusted for any changes in the network traffic flow by the additive increase / multiplicative decrease (AIMD) method, e.g., adding a certain constant to the size of CWND if all segments are received and acknowledged, or multiplying it by a reduction factor otherwise. As used herein, a sender node can also include a switch or router or other device that can be used to transmit data. CWND can be maintained by the sender node, the receiver node, and / or the end node.

[0024] As used herein, "network congestion" in computer networking may refer to a situation where a computer network is unable to handle or carry data by a device (such as a network node (end node), a destination device, a router, a switch, or a link). For example, a sender node transmits data packets at a flow rate faster than the capacity of the receiving device. In some embodiments, during network congestion, a device may queue data packets in a buffer, and after the buffer is full, new packets may be discarded, e.g., packet loss. Network congestion degrades the quality of service, e.g., due to packet loss.

[0025] As used herein, "link congestion" in computer networking may refer to a situation where a network node or a link is carrying more data than it can handle, e.g., exceeding the available bandwidth, where an increasing increase in the load may only result in a small increase or even a decrease in network throughput.

[0026] As used herein, "communication protocol" in computer networking may refer to a set of rules used by two or more devices in a computer network to transmit information or data. The protocol may define the rules, syntax, semantics, and synchronization of communication as well as possible error recovery methods. In some embodiments, the communication protocol may be the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) and / or may be the Internet Protocol (IP), the Post Office Protocol (POP), the Simple Mail Transfer Protocol (SMTP), the File Transfer Protocol (FTP), the Hypertext Transfer Protocol (HTTP), the Hypertext Transfer Protocol Secure (HTTPS), Telnet, Gopher, etc. The protocol may be implemented by hardware, software, or a combination thereof.

[0027] Many network congestion controllers may use packet loss as an indicator of network congestion and treat packet loss as a severe congestion event. Then, the network congestion controller may be programmed, designed, or otherwise configured to reduce the size of the congestion window (CWND) based on receiving an indication of packet loss, e.g., the size of the congestion window of one or more sender nodes or end nodes, regardless of the source of the congestion. For example, in TCP, previous congestion control algorithms or controllers may use CWND to limit the total number of unacknowledged packets that may exist in an end-to-end transmission, e.g., the bytes in transit, where if the number of unacknowledged segments equals the maximum available size of CWND (e.g., the available bandwidth), the sender stops sending data until more ACKs are received. Additive Increase / Multiplicative Decrease (AIMD) may be used as the main feedback control algorithm for previous congestion control algorithms or controllers to adjust the TCP flow of data packets, e.g., by adjusting the size of CWND. Assuming packet loss is used as the congestion indicator, the basic AIMD algorithm may be as follows:

[0028] Additive increase: Increase the CWND by a fixed amount (e.g., one MSS) every round-trip time (RTT) without packet loss.

[0029] Multiplicative decrease: Multiply the congestion window by a multiplicative factor (e.g., 1 / 2) every RTT when packet loss occurs.

[0030] That is, previous congestion controllers were designed, programmed, or otherwise configured to arbitrarily apply multiplicative decrease to the size of the CWND, e.g., based solely on any indication of packet loss, resulting in the classical "sawtooth" pattern in TCP flows based on congestion control results. However, this multiplicative decrease in CWND size can be detrimental to the quality of service of users, e.g., causing applications such as search, cloud computing, social networking, shopping, big data analytics, gaming, communication, etc. to have poor performance, due to the high packet loss caused by the multiplicative decrease in CWND size.

[0031] That is, any arbitrary reduction in data packet transmission (e.g., reduction in CWND size) based on any indication of packet loss may unnecessarily affect computer network performance. For example, when packet loss is due to reasons other than link congestion, reducing the congestion window (CWND) may unnecessarily degrade computer network performance without addressing the underlying root condition that causes packet loss. For example, packet loss may be a random event rather than a repeated event due to physical errors causing packet loss. Therefore, any arbitrary reduction in CWND size does not mitigate packet loss.

[0032] The features in the embodiments disclosed herein can provide methods, programs, devices, and systems for improving computer network performance by making different responses to packet losses caused by different network congestion events. In some embodiments, the methods, programs, devices, and systems can be designed, programmed, or otherwise configured to distinguish or determine various causes of packet losses and control network traffic differently based on the various causes of packet losses. In some embodiments, the methods, devices, and systems can use network congestion signals, such as explicit congestion notification (ECN), round-trip time (RTT), or in-band network telemetry (INT), to distinguish or determine whether a packet loss is due to link congestion or different causes of packet loss, such as physical layer problems or hardware errors, cyclic redundancy check (CRC) failures, software errors, etc. Thus, by having methods, programs, devices, and systems that respond to packet losses based on the determined causes of packet losses, computer network performance (and quality of service) can be improved. For example, reducing the congestion window (CWND) may degrade computer network performance when a packet loss is due to a cause other than link congestion. Therefore, methods, devices, programs, and systems as discussed herein can be provided such that network traffic can be maintained when it is determined that the cause of a packet loss is not due to link congestion, and network traffic is reduced only when it is determined that the cause of a packet loss is due to link congestion. The methods, devices, and systems can also be used to track physical layer problems along a path or link, which can be used to alert network operators to replace any problematic devices, links, etc.

[0033] Figure 1 is a schematic diagram of an example computer network networking 100 arranged according to at least some of the embodiments described herein for controlling network traffic.

[0034] System 100 may include devices 105, 110, 115, 120, 130, 140, 150, network 160, router 170, and / or network switches 180 and 190. It should be understood that Figure 1 only an illustrative number of devices (105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190) and / or networks are shown. The embodiments described herein are not limited to the number of devices and / or networks described. That is, the number of devices and / or networks described herein is for illustrative purposes only and is not intended to be limiting.

[0035] According to at least some example embodiments, devices 105, 110, 115, 120, 130, 140, and / or 150 can be various electronic devices that can act as sender nodes, end nodes, and / or receiver nodes. The various electronic devices can include, but are not limited to, mobile devices (such as smartphones), tablet computers, e-book readers, laptop computers, desktop computers, servers, data centers, and / or any other suitable electronic devices.

[0036] According to at least some example embodiments, one or more of the devices 105, 110, 115, 120, 130, 140, and / or 150 can be a server or a data center for providing various services to users who use one or more of the other devices. The server can be implemented by a distributed server cluster including multiple servers, or can be implemented by a single server.

[0037] According to at least some example embodiments, network 160 can be a medium for communicatively connecting one or more of the devices 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190. Network 160 can be the Internet, a local area network (LAN), a wide area network (WAN), a local interconnect network (LIN), the cloud, etc. Network 160 can be implemented through various types of connections, such as wired communication links, wireless communication links, fiber optic cables, etc.

[0038] According to at least some example embodiments, router 170 can be provided in network 160 for selecting a path for data packets (e.g., between computer networks). In some embodiments, router 170 can direct network traffic between a computer network and the Internet and a destination device (such as one or more of the devices 105, 110, 115, 120, 130, 140, 150).

[0039] According to at least some example embodiments, switches 180 and 190 can be provided in network 160 for connecting between devices 105, 110, 115, 120, 130, 140, 150, and router 170, e.g., providing communication links. In some embodiments, switches 180 and 190 can be provided for managing network traffic across the network (e.g., from the router and / or sender node and / or end node) by forwarding data packets to / from (multiple) devices (e.g., only to one or more of the (multiple) devices that the data packet is addressed to).

[0040] Users can use one or more of the devices 105, 110, 115, 120, 130, 140, 150 to interact with each other via the network 160. For example, as sender nodes and / or receiver nodes. Various applications such as search, cloud computing, social networking, shopping, big data analysis, gaming, communication, etc. or their localized interfaces can be installed on the devices 105, 110, 115, 120, 130, 140, and / or 150.

[0041] It should be understood that software applications or services according to the embodiments described herein and / or according to the services provided by the service provider can be executed by any one or more of the devices 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190. Therefore, the apparatus for the software application and / or service can be arranged in the devices 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190.

[0042] It should also be understood that when the service is not remotely executed, the system 100 may not include the network 160, but only includes the devices 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190.

[0043] It should also be understood that each of the devices 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190 may include one or more processors, a memory, and a storage device storing one or more programs. Each of the devices 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190 may also include an Ethernet connector, a Wi-Fi receiver, etc. When executed by one or more processors, the one or more programs may cause the one or more processors to perform the (multiple) methods described in any of the embodiments described herein. In addition, it should be understood that according to the embodiments described herein, a computer-readable non-volatile medium may be provided. The computer-readable medium stores a computer program. The computer program is for performing the (multiple) methods described in any of the embodiments described herein when executed by a processor.

[0044] Figure 2 is a schematic diagram of an example network 200 arranged according to at least some of the embodiments described herein. The network 200 can be designed, programmed, or otherwise configured to provide for use in one or more devices (e.g., Figure 1A medium that provides a communication link between 105, 110, 115, 120, 130, 140, 150, 180, 190). Network 200 may include one or more routers for selecting a path for data packets via switch 280 and link and transmitting them to the destination device(s), and switch 280 and link are designed, programmed, and / or otherwise configured to manage network traffic across the network by transmitting received data packets (e.g., via network address, etc.) only to one or more devices targeted by the data packet. In an example embodiment, network 200 may be Figure 1 Network 160, and may include sender nodes and / or end nodes, switches (e.g., Figure 1 180 and / or 190), routers (e.g., Figure 1 170), etc.

[0045] In an example embodiment, network 200 may include one or more sender nodes (e.g., Figure 1 105, 110, 115, 120, 130, 140, 150, 180, 190) that can transmit data packets through network 200. The sender node may transmit data packets through network 200 to one or more switches 280, one or more end nodes 285, and / or one or more routers (e.g., Figure 1 170) via a link (e.g., L1, L2, L3) (e.g., a communication channel).

[0046] In some embodiments, one or more switches 280A…280N may be connected to have a daisy-chain topology, e.g., a communication link from switch 280A of S2 to switch 280B of (multiple) S1 to (multiple) S0 switches to end node 285 for transmitting / receiving data packets. Unless the context otherwise requires, reference will generally be made to switch 280. Switch 280 may be provided for managing network traffic across the network (network traffic from routers (e.g., Figure 1 170) and / or other switches 280), e.g., by forwarding data packets to / from the destination device(s) or end node(s), e.g., forwarding data packets only to / from one or more (multiple) devices targeted by the data packet, to manage network traffic across the network (network traffic from routers (e.g., Figure 1 170) and / or other switches 280). In some embodiments, switch 280 may be a layer 2 and / or layer 3 layer, e.g., a data link layer and / or a network layer. In some embodiments, one or more of switches 280 may be connected to end node 285 having a congestion control algorithm or controller (CC) 286, which is designed, programmed, or otherwise configured for packet loss analysis.

[0047] In some embodiments, the end node 285 can be a data center or a destination device that includes a congestion control algorithm or controller 286 to control the sending rate, e.g., by sending a signal to the sending node or controlling the network traffic at the end node 285. In some embodiments, the congestion control algorithm or controller 286 can be designed, programmed, or otherwise configured to detect packet loss of data packets in the network traffic, e.g., from one or more of the sending node, link, router, etc. Packet loss can be detected by any method for detecting packet loss, including but not limited to through the underlying communication protocol, e.g., TCP, pinging network devices, using packet loss testing tools (e.g., using WebRTC), using marked packets, etc.

[0048] In some embodiments, the congestion control algorithm or controller 286 corresponding to the end node 285 can be designed, programmed, or otherwise configured to control the sending rate by adjusting the size of the CWND. The CWND can have a bandwidth or maximum size (e.g., MSS value) corresponding to the capacity of data packets that can be received by the end node, which can be a private value maintained by the end node, e.g., not advertised or exchanged between the sender and the receiver. Although the congestion control algorithm or controller 286 can use the CWND for additive increase, e.g., increasing the size of the CWND by a fixed amount (e.g., one maximum segment size or maximum packet size (MSS) (e.g., the maximum amount of data that TCP can receive in a single segment)) in each RTT without packet loss, the congestion control algorithm or controller 286 can be designed, programmed, or otherwise configured to decrease the size of the CWND only when packet loss is detected due to link congestion. That is, the congestion control algorithm or controller 286 described herein is designed, programmed, or otherwise configured to distinguish various causes of packet loss and have different responses, e.g., controlling network traffic based on the cause of packet loss (e.g., due to link congestion (or link failure) or different causes of packet loss such as hardware errors like physical layer problems, software errors, cyclic redundancy check (CRC) failures) (e.g., problems that may occur randomly and may not repeat at the same location)) rather than treating packet loss as severe congestion and decreasing the size of the CWND regardless of the source of congestion.

[0049] For example, in some embodiments, the congestion control algorithm or controller 286 may be designed, programmed, or otherwise configured to detect network congestion signals. The network congestion signals may be one or more of explicit congestion notification (ECN), round-trip time (RTT), or in-band network telemetry (INT), but are not limited thereto. In some embodiments, the network congestion signal may be the detection of a timeout, e.g., due to a link being down or high congestion in both directions. Thus, the congestion control algorithm or controller 286 may be designed, programmed, or otherwise configured to detect one or more network congestion signals among network congestion signals (e.g., RTT, ECN, INT, or timeout), and determine whether packet loss is due to link congestion or different reasons for packet loss, such as physical layer problems or hardware errors, CRC failures, hardware problems, which occur randomly and do not repeat at the same location.

[0050] In an example embodiment, if there is congestion, the sender may receive ECN / INT information about the congestion before packet loss. If packet loss is detected, e.g., via a duplicate acknowledgment (ACK), but no ECN / INT information is received, the congestion control algorithm or controller 286 may be configured to treat the packet loss as a different reason for packet loss (rather than due to link congestion), and the congestion control algorithm or controller 286 may not decrease or reduce the size of the CWND, e.g., maintain network traffic. However, if the congestion control algorithm or controller 286 detects congestion in the network traffic and detects a network congestion signal, the congestion control algorithm or controller 286 may be configured to treat the packet loss as due to link congestion, and the congestion control algorithm or controller 286 may reduce the size of the CWND according to the solutions described and enumerated herein.

[0051] In some embodiments, the detection of network congestion signals may include detecting or determining ECN / INT information in two time windows, e.g., to detect congestion-based packet loss. These two time windows may be referred to as the pre-loss window and the post-loss window, and the sizes of these two windows may be initialized and updated based on the packet loss rate environment and real-time network conditions (e.g., network traffic and flows of the underlying network). For example, in some embodiments, a connection including a wireless connection may have the highest packet loss rate, a long Internet connection may have a medium packet loss rate, and a data center network may have the lowest packet loss rate and the shortest RTT. Thus, the data center environment may have shorter pre-loss and post-loss windows. That is, in some embodiments, the size of the CWND may be at the same level as the RTT. In some embodiments, due to the minimal likelihood of packet loss, the data center may use a relatively large window size.

[0052] For example, when packet N is lost, there can be 4 packets before packet N in the window before the loss, and 2 packets after packet N in the window after the loss. In this way, the receiver (or end node) can send the packet N loss information (e.g., negative acknowledgment (NACK)) back to the sender, and also send information on whether packets N+1 and N+2 have experienced any congestion. If any packet in the packets within these two windows is detected to have experienced congestion, it is determined that the cause of the packet loss is due to link congestion. That is, if ECN / INT information is received within one of the two time windows, the congestion control algorithm or controller 286 can regard the packet loss as due to link congestion, and can reduce the size of the CWND, for example, by reducing the size of the CWND by at least one multiplicative factor, such as one-tenth, one-quarter, one-half, etc.

[0053] On the other hand, in another exemplary embodiment, when a short burst from another flow is detected and the sender does not receive any ECN / INT information in either the window before the loss or the window after the loss, the congestion control algorithm or controller 286 can regard the packet loss as due to other reasons for the packet loss, and can not reduce the size of the CWND because the congestion may have ended.

[0054] In some embodiments, the congestion control algorithm or controller 286 can include a modified additive increase / multiplicative decrease (AIMD) algorithm. For example, as Figure 3 shown, the congestion control algorithm or controller 286 can be designed, programmed, or otherwise configured to initially start the CWND with a predetermined window size (e.g., 5, 10, 20, 30, or 40 MSS). Then, as each ACK (for each RTT) is received (e.g., no packet loss is detected), the value of the congestion window size can increase or grow by a fixed amount, e.g., 1 MSS. When the congestion control algorithm or controller 286 detects that packet loss has occurred, e.g., when the network traffic reaches the maximum CWND size corresponding to the maximum capacity of the end node (e.g., 80 MSS) or due to physical layer or hardware problems, the congestion control algorithm or controller 286 controls the network traffic in the computer network.

[0055] That is, as Figure 3As shown, the congestion control algorithm or controller 286 may have a CWND that is initiated or started with a predetermined window size (e.g., 48 MSS), which increases or grows by a fixed amount (e.g., 1 MSS) with each ACK received (for each RTT) (e.g., when no packet loss is detected). When the congestion control algorithm or controller 286 detects packet loss of data packets in network traffic, the congestion control algorithm or controller 286 may be configured to determine the cause of the packet loss and control the network traffic in the computer network based on the cause of the packet loss. When the cause of the packet loss is determined to be due to link congestion (e.g., more data than the end node can handle), the congestion control algorithm or controller 286 may (e.g., by a multiplicative factor (e.g., half)) reduce the size of the CWND for the network traffic, e.g., from 80 MSS to 40 MSS.

[0056] However, as Figure 4 shown, when the congestion control algorithm or controller 286 determines that the cause of the packet loss is not due to link congestion (e.g., different causes of packet loss such as physical layer or hardware or software problems), the network traffic is maintained, e.g., the size of the CWND is not reduced to limit the network traffic through the end node (as shown in line 410). Thus, by having methods, devices, and systems that respond to packet loss based on the cause of the packet loss, computer network performance can be improved. For example, reducing the congestion window (CWND) may degrade computer network performance when the packet loss is due to reasons other than link congestion.

[0057] That is, as shown in line 420, existing congestion control algorithms or controllers are designed, programmed, or otherwise configured to reduce or lower the size of the CWND whenever packet loss is detected, including physical layer or hardware or software problems, where the network traffic is negatively affected, e.g., by drastically reducing the amount of network traffic and affecting computer network performance, which may have an adverse impact on the quality of service.

[0058] Returning to Figure 2, in some embodiments, the (multiple) end nodes 285 may communicate with a network error analyzer 295 that is designed, programmed, or otherwise configured to measure network parameters of network 200, e.g., in the context of packet loss, including but not limited to routing, location, timestamp, etc., which may be information from controller 286. In some embodiments, the network error analyzer 295 may be designed, programmed, or otherwise configured to further analyze the time and location of packet loss that occurs not due to network congestion, and may determine where in the computer network the packet loss occurs, e.g., at certain network devices (such as switches, end nodes, routers, links, etc.). Thus, the network error analyzer 295 may be designed, programmed, or otherwise configured to use this information to alert a network operator (e.g., an operator of a data center, an Internet network, etc.) to fix any hardware, software, or other issues with the network device or link, such as a network with an old network architecture (such as link jitter). That is, while in a previous data center or network, network devices and / or links may be replaced periodically, e.g., every 5 years, to proactively address physical layer or hardware or software issues, with a network error analyzer 295 configured as described herein to determine where in the computer network packet loss can occur, only the network devices and / or links that cause packet loss can be identified and repaired / replaced, which reduces the cost of maintaining the network and / or data center. Additionally, by being able to detect network congestion signals and using the network congestion signals, additional capital expenditures on monitors for monitoring errors on each device can be avoided, e.g., avoiding additional overhead, and the need to sample the network can be avoided, which can reduce available bandwidth, since the congestion controller or algorithm described herein uses the signals already provided therein.

[0059] Figure 5 is a flowchart showing an example processing flow 500 for controlling network traffic of a computer network using a communication protocol according to at least some embodiments described herein.

[0060] It should be understood that unless otherwise specified, the processing flow 500 disclosed herein may be executed by one or more processors, such as a local device management CPU of a device (e.g., a router, a switch, etc.), including, for example Figure 1 the processors of one or more of the devices 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190, Figure 6 the CPU 605, and / or any other suitable processor.

[0061] It should also be understood that the processing flow 500 may include one or more operations, actions, or functions illustrated by one or more of the one or more boxes 510, 520, 530, 540, 550, 560. These various operations, functions, or actions may, for example, correspond to software, program code, or program instructions executable by a processor, which causes the functions to be executed. Although illustrated as discrete boxes, obvious modifications can be made, for example, two or more of the boxes can be reordered; more boxes can be added; and the various boxes can be divided into additional boxes, combined into fewer boxes, or eliminated, depending on the desired implementation. It should be understood that operations including initialization, etc. can be performed before the processing flow 500. For example, system parameters and / or application parameters can be initialized. It should be understood that Figures 2 - 4 the processes, operations, or actions described in

[0062] can be implemented or executed by a processor. The processing flow 500 may start at box 510.

[0063] At box 510 (detection), the processor of the corresponding device can detect packet loss of data packets in the network traffic received from one or more sender nodes. Packet loss can be detected by any existing method for detecting packet loss, including but not limited to through the underlying communication protocol, for example, TCP, pinging network devices, using packet loss test tools (e.g., using WebRTC), using marked packets, etc. The processing can proceed from box 510 to box 520 or 530.

[0064] At block 530 (Determine), when packet loss is detected, the processor may determine the cause of the packet loss. For example, in some embodiments, the determining step 520 may include block 540 (Detect), where the processor may be designed, programmed, or otherwise configured to detect a network congestion signal. The network congestion signal may be one or more of explicit congestion notification (ECN), round-trip time (RTT), or in-band network telemetry (INT), but is not limited thereto. In some embodiments, the network congestion signal may be the detection of a timeout, e.g., due to a link being down or high congestion in both directions. Thus, the processor may be designed, programmed, or otherwise configured to detect one or more network congestion signals (such as, RTT, ECN, INT, or timeout), and based on the network congestion signal, determine whether the packet loss is due to link congestion or due to different causes of packet loss, such as physical layer problems or hardware errors, CRC failures, hardware problems, which occur randomly and do not repeat at the same location.

[0065] In some embodiments, the detection of the network congestion signal may include detecting or determining ECN / INT information in at least two time windows, e.g., to detect congestion-based packet loss. These two time windows may be referred to as the pre-loss window and the post-loss window, and the sizes of these two windows may be initialized and updated based on the packet loss rate environment and real-time network conditions (e.g., network traffic and flows of the underlying network). For example, when packet N is lost, there may be 4 packets before packet N in the pre-loss window, and 2 packets after packet N in the post-loss window. Thus, the receiver (or end node) may send packet N loss information (e.g., negative acknowledgment (NACK)) back to the sender, and also send information on whether any congestion was experienced by packets N+1 and N+2. If any of the packets within these two windows are detected to have experienced congestion, it is determined that the cause of the packet loss is due to link congestion. Otherwise, the processor may be designed, programmed, or otherwise configured to determine that the cause of the packet loss is due to different causes of packet loss, such as physical layer problems or hardware errors, CRC failures, hardware problems, which occur randomly and do not repeat at the same location.

[0066] In an example embodiment, if there is congestion, the sender can receive ECN / INT information about the congestion before packet loss. If packet loss is detected, e.g., via a duplicate acknowledgment (ACK), but no ECN / INT information is received, the processor can be configured to treat the packet loss as a different cause of packet loss (rather than due to link congestion). In another example embodiment, when a short burst from another flow is detected and the sender does not receive any ECN / INT information in either the window before loss or the window after loss, the processor can treat the packet loss as another cause of packet loss, e.g., not link congestion because the congestion may have ended. The process can proceed from block 540 to block 550.

[0067] At block 550 (maintain), the processor can be designed, programmed, or otherwise configured to control network traffic in a computer network by maintaining the network traffic because the cause of the packet loss is not due to link congestion. That is, the processor (at the end node) does not decrease the size of the CWND, but rather maintains the flow rate of the same or similar network traffic. The process can proceed from block 550 to block 510.

[0068] However, if the processor detects congestion in the network traffic and detects a network congestion signal, the processor can be configured to treat the packet loss as due to link congestion. The process can proceed from block 540 to block 560.

[0069] At block 560 (reduce), the processor can be designed, programmed, or otherwise configured to control network traffic in a computer network by decreasing the size of the CWND of the network traffic because the cause of the packet loss is due to link congestion. In some embodiments, decreasing the size of the CWND can include decreasing or reducing the size of the CWND, e.g., by at least one multiplicative factor such as one-tenth, one-quarter, one-half, etc. The process can proceed from block 560 to block 510.

[0070] That is, while many network congestion controllers or algorithms based on packet loss can treat packet loss as a severe congestion event and decrease the size of the CWND regardless of the source of the congestion, the congestion control algorithm or controller described herein is designed, programmed, or otherwise configured to distinguish the various causes of packet loss and have different responses based on the cause of the packet loss (e.g., due to link congestion (or link failure) or different causes of packet loss (e.g., hardware errors such as physical layer problems, software errors, cyclic redundancy check (CRC) failures, e.g., problems that may occur randomly and may not repeat at the same location)), e.g., to control network traffic.

[0071] Figure 6is a schematic structural diagram of an example computer system 600 arranged according to at least some embodiments described herein and suitable for implementing devices (e.g., Figure 1 105, 110, 115, 120, 130, 140, 150, 170, 180, and / or 190). It should be understood that Figure 6 the computer system shown is for illustration only and does not limit the functions and applications of the embodiments described herein.

[0072] As shown, the computer system 600 may include a central processing unit (CPU) 605. The CPU 605 may perform various operations and processes based on a program stored in a read-only memory (ROM) 610 or a program loaded from a storage device 640 into a random access memory (RAM) 615. The RAM 615 may also store various data and programs required for the operation of the system 600. The CPU 605, ROM 610, and RAM 615 may be connected to each other via a bus 620. An input / output (I / O) interface 625 may also be connected to the bus 620.

[0073] Components connected to the I / O interface 625 may further include: an input device 630, which includes a keyboard, a mouse, a digital pen, a graphics tablet, etc.; an output device 635, which includes a display such as a liquid crystal display (LCD), a speaker, etc.; a storage device 640, which includes a hard disk, etc.; and a communication device 645, which includes a network interface card such as a LAN card, a modem, etc. The communication device 645 may perform communication processing via a network such as the Internet, WAN, LAN, LIN, cloud, etc. In one embodiment, a drive 650 may also be connected to the I / O interface 625. A removable medium 655 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. may be installed on the drive 650 as needed, so that a computer program read from the removable medium 655 may be installed in the storage device 640.

[0074] It should be understood that the processes described with reference to Figure 5 the flowcharts and / or the processes described in other figures may be implemented as computer software programs or hardware. A computer program product may include a computer program stored in a computer-readable non-volatile medium. The computer program includes program code for performing the methods shown in the flowcharts and / or the GUI. In this embodiment, the computer program may be downloaded and installed from a network via the communication device 645, and / or may be installed from the removable medium 655. When executed by the central processing unit (CPU) 605, the computer program may implement the above functions specified in the methods of the embodiments disclosed herein.

[0075] It should be understood that the disclosed content and other solutions, examples, embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in a combination of one or more of them. The disclosed content and other embodiments can be implemented as one or more computer program products, that is, one or more computer program instruction modules encoded on a non-transitory computer-readable medium for execution by, or for controlling the operation of, a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a storage device, a composition of matter that affects 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, programmable processors, computers, or multiple processors or computers. In addition to hardware, the apparatus may also include code that creates an execution environment for the computer programs being discussed, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0076] A computer program (also referred to 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. The program can be stored in a part of a file that holds other programs or data (for example, one or more scripts in a markup language document), stored in a single file dedicated to the program being discussed, or stored in multiple coordinated files (for example, files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to be executed on one or more computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0077] The processes and logical flows described in this document can be executed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be executed by dedicated logic circuitry (such as field-programmable gate arrays, application-specific integrated circuits, etc.), and the apparatus can also be implemented as dedicated logic circuitry (such as field-programmable gate arrays, application-specific integrated circuits, etc.).

[0078] Processors suitable for executing computer programs include, for example, general and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing the instructions and data. Generally, a computer will also include one or more mass storage devices (such as magnetic disks, magneto-optical disks, or optical disks) for storing data, or be operatively coupled to receive data from one or more mass storage devices or transfer data to one or more mass storage devices, 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 memory devices, including, for example, semiconductor memory devices such as erasable programmable read-only memory, electrically erasable programmable read-only memory, and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and compact disk read-only memory and digital video disk read-only memory disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0079] It should be understood that different features, variations, and numerous different embodiments have been shown and described in detail. What is sometimes described in this application in terms of specific embodiments is done for illustrative purposes only and is not intended to limit or imply that the inventive concept is only one particular embodiment or specific embodiment. It should be understood that the present disclosure is not limited to any single specific embodiment or enumerated variation. Many modifications, variations, and other embodiments will occur to those skilled in the art, and these embodiments are intended to and are in fact covered by the present disclosure. Indeed, the scope of the present disclosure should be determined by appropriate legal interpretation and construction of the present disclosure, including equivalents as understood by those skilled in the art relying on the complete disclosure at the time of filing.

[0080] Aspects:

[0081] It should be understood that any of the aspects may be combined with each other.

[0082] Aspect 1. A method for controlling network traffic in a computer network using a communication protocol, the method comprising: detecting packet loss of data packets in network traffic received from one or more sender nodes; determining a cause of the packet loss; and controlling network traffic in the computer network based on the determined cause of the packet loss, wherein the cause of the packet loss is due to link congestion or different causes of packet loss.

[0083] Aspect 2. The method according to aspect 1, wherein determining the cause of the packet loss comprises: detecting a network congestion signal, wherein when the network congestion signal is detected, it is determined that the cause of the packet loss is due to link congestion.

[0084] Aspect 3. The method according to aspect 2, wherein the network congestion signal includes one or more of explicit congestion notification (ECN), round-trip time (RTT), or in-band network telemetry (INT).

[0085] Aspect 4. The method according to any one of aspects 1-3, wherein controlling network traffic includes: when the cause of packet loss is due to link congestion, reducing the size of the congestion window for the network traffic.

[0086] Aspect 5. The method according to aspect 4, wherein reducing the size of the congestion window includes reducing the size of the congestion window by a multiplicative factor.

[0087] Aspect 6. The method according to aspect 5, wherein the multiplicative factor is at least half or a quarter of the size of the congestion window.

[0088] Aspect 7. The method according to any one of aspects 2-6, wherein detecting the network congestion signal is performed in at least two time windows, and when the network congestion signal is detected in one of the at least two time windows, the method further includes: determining that the cause of packet loss is due to link congestion, and reducing network traffic.

[0089] Aspect 8. The method according to any one of aspects 1-3 and 7, wherein determining the cause of packet loss includes: detecting the network congestion signal, and when the network congestion signal is not detected, maintaining network traffic.

[0090] Aspect 9. The method according to any one of aspects 1-3, further includes: increasing the amount of network traffic by increasing the size of the congestion window at the end node by a fixed amount until packet loss is detected.

[0091] Aspect 10. The method according to aspect 9, wherein the fixed amount is at least one maximum segment size (MSS) of the congestion window.

[0092] Aspect 11. A congestion controller in a computer network using a communication protocol, the congestion controller includes: a processor configured to execute instructions, wherein the instructions when executed cause the processor to: detect packet loss of data packets in network traffic received from one or more sender nodes; determine the cause of the packet loss; and control network traffic in the computer network based on the determined cause of the packet loss, wherein the cause of the packet loss is due to link congestion or different causes of packet loss.

[0093] Aspect 12. The congestion controller according to aspect 11, wherein the processor is further caused to: detect the network congestion signal, and when the network congestion signal is detected, determine that the cause of the packet loss is due to link congestion.

[0094] Aspect 13. The congestion controller according to any one of Aspects 11 - 12, wherein the network congestion signal includes one or more of explicit congestion notification (ECN), round - trip time (RTT), or in - band network telemetry (INT).

[0095] Aspect 14. The congestion controller according to any one of Aspects 12 - 13, wherein the congestion controller is configured to: when the reason for packet loss is due to link congestion, control network traffic by reducing the size of the congestion window for network traffic.

[0096] Aspect 15. The congestion controller according to any one of Aspects 12 - 14, wherein the congestion controller includes at least two time windows, and the congestion controller is configured to: when a network congestion signal is detected in at least one of the at least two time windows, reduce network traffic.

[0097] Aspect 16. The congestion controller according to any one of Aspects 11 - 13, wherein the processor is further caused to determine the reason for packet loss by: detecting a network congestion signal, and when no network congestion signal is detected, maintaining network traffic.

[0098] Aspect 17. A non - transient computer - readable medium having computer - executable instructions stored thereon, the instructions when executed causing one or more processors of an end - node of a computer network using a communication protocol to perform operations, the operations including: detecting packet loss of data packets in network traffic received from one or more sender nodes; determining the reason for the packet loss; and controlling network traffic in the computer network based on the determined reason for the packet loss, wherein the reason for the packet loss is due to link congestion or a different reason for packet loss.

[0099] Aspect 18. The non - transient computer - readable medium according to Aspect 17, wherein determining the reason for the packet loss includes: detecting a network congestion signal, and when a network congestion signal is detected, determining that the reason for the packet loss is due to link congestion.

[0100] Aspect 19. The non - transient computer - readable medium according to any one of Aspects 17 - 18, wherein controlling network traffic includes: when the reason for the packet loss is due to link congestion, reducing the size of the congestion window of the network traffic at the end - node.

[0101] Aspect 20. The non - transient computer - readable medium according to Aspect 17, wherein determining the reason for the packet loss includes: detecting a network congestion signal, and when no network congestion signal is detected, maintaining network traffic.

[0102] The terms used in this specification are intended to describe particular embodiments and are not intended to be limiting. Unless otherwise expressly stated, the terms "a," "an," and "the" also include plural forms. As used in this specification, the terms "comprising" and / or "including" specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, and / or components.

[0103] In regard to the foregoing description, it should be understood that changes may be made in detail, particularly in the structural materials employed as well as in the shape, size, and arrangement of the parts, without departing from the scope of the disclosure. The specification and the described embodiments are merely exemplary, and the true scope and spirit of the disclosure are indicated by the appended claims.

Claims

1. A method for controlling network traffic of a computer network using a communication protocol, the method comprising: detecting packet loss of data packets in network traffic received from one or more sender nodes; determining a cause of the packet loss; as well as controlling network traffic in the computer network based on the determined cause of the packet loss, The reasons for the packet loss may be due to link congestion or different reasons for packet loss.

2. The method of claim 1 , wherein determining the cause of the packet loss comprises: Detect network congestion signals, When the network congestion signal is detected, it is determined that the cause of the packet loss is due to link congestion. 3 . The method of claim 2 , wherein the network congestion signal comprises one or more of: an explicit congestion notification (ECN), a round trip time (RTT), or an in-band network telemetry (INT).

4. The method of claim 1, wherein controlling the network traffic comprises: When the cause of the packet loss is due to congestion on the link, the size of the congestion window for the network traffic is reduced.

5. The method of claim 4, wherein reducing the size of the congestion window comprises: The size of the congestion window is reduced by a multiplicative factor.

6. The method of claim 5, wherein the multiplicative factor is at least half, or one quarter, the size of the congestion window.

7. The method according to claim 2, wherein detecting the network congestion signal is performed in at least two time windows, Wherein, when the network congestion signal is detected in one of the at least two time windows, the method further includes: determining that the packet loss is due to link congestion, and Reduce the network traffic.

8. The method of claim 1 , wherein determining the cause of the packet loss comprises: Detect network congestion signals, When the network congestion signal is not detected, the network flow is maintained.

9. The method according to claim 1, further comprising: The amount of network traffic is increased by increasing the size of the congestion window at the end node by a fixed amount until the packet loss is detected.

10. The method of claim 9, wherein the fixed amount is at least one maximum segment size (MSS) of the congestion window.

11. A congestion controller in a computer network using a communication protocol, the congestion controller comprising: A processor configured to execute instructions, wherein the instructions, when executed, cause the processor to perform the method according to any one of claims 1-10.

12. A non-transitory computer-readable medium having computer-executable instructions stored thereon, which, when executed, cause one or more processors of an end node of a computer network using a communication protocol to perform the method according to any one of claims 1-10.

Images