Method and system for evaluating data connectivity based on congestion control

Abstract

A method and system for evaluating data connections based on congestion control is described. In one embodiment, the first device receives a request to perform a performance test between the first and second devices. The first device transmits test data to the second device via a first data connection according to a congestion window. The first device receives feedback based on at least a portion of the transmitted test data and determines the bandwidth or data transfer rate of the first data connection based on the feedback and the congestion window. The first device transmits to the second device via the second data connection the bandwidth or data transfer rate that the device will present.

Description

Technical Field

[0001] The disclosed embodiments relate to a method and system for efficiently evaluating a data connection between at least two devices based on network congestion control. Still other embodiments will also be described.

Background Art

[0002] In recent years, the number of media data streaming devices such as computer tablets and smartphones has increased rapidly, and users stream a significant amount of data. For example, streaming a 4K movie requires approximately 9 gigabytes (GB) per hour of the movie. As a result, the computing network to which media streaming devices connect to the Internet requires high bandwidth to handle data, and bandwidth is related to the capacity of the network to transmit data. Specifically, bandwidth may be the maximum data transfer rate (or maximum transmission rate) that the underlying network can achieve without loss (or with minimal loss). This is particularly applicable to cases where a large number of computing devices are exchanging data via a given network.

Summary of the Invention

Problems to be Solved by the Invention

[0003] The bandwidth of an internet connection (e.g., internet speed) can be measured by using an internet speed test. Traditional speed tests rely on massive downloads that saturate the connection to measure how much data can be delivered without loss. For example, during a traditional test, a client device may request an internet speed test server to transmit as much data as possible to load the internet connection up to its saturation point. In practice, the client device may instruct the server to perform the test by transmitting a specific amount of bytes (of data files). For example, after all the requested data has been transmitted to the client device and the saturation point is deemed to have been "reached," or when the timer expires, the client device determines and records the bandwidth, for example, by measuring the rate at which the data was received, or by determining how long it took to transmit the requested amount of data. This relies on transmitting large amounts of data on a high-bandwidth connection. Data connections such as modern 5G connections can consume more than 1,000 megabytes (MB) per test. For wireless carriers that sell consumers tiered packages based on data usage, a single internet speed test over a wireless connection can consume more than 25% of a customer's monthly data allocation. Therefore, efficient performance testing is needed to evaluate data connectivity between devices. [Means for solving the problem]

[0004] This disclosure relates to a method and system for performing efficient evaluation of a data connection based on a congestion control algorithm that controls how many data packets may enter the network based on the size of the congestion window at any given time. In an example, a first electronic device (e.g., a transmitting device) may receive a request to perform a performance test of a first data connection between the first device and a second electronic device (e.g., a receiving device). For example, the receiving device may be a client device such as a smartphone, while the transmitting device may be a remote server. In detail, the receiving device may establish a Transmission Control Protocol (TCP) connection or a Quick User Datagram Protocol (UDP) Internet Connection (QUIC) connection with the transmitting device. The transmitting device transmits data (e.g., test data or any type of data) over the first data connection according to the congestion window. In this case, the congestion control algorithm of the transmitting device may initiate congestion control and begin transmitting data, and the algorithm may expand the congestion window, thereby increasing the data transmission rate over time.

[0005] A transmitting device may receive feedback from a receiving device based on at least a portion of the transmitted data. In an example, the feedback may include an indication of a packet loss event in which one or more transmitted data packets are lost, and / or an acknowledgment that the receiving device has received one or more data packets. In one embodiment, the transmitting device may determine one or more characteristics of the first data connection based on the feedback. For example, based on the acknowledgment, the transmitting device may determine at least one round-trip time (RTT) of a data packet, at least one jitter of a data packet, or packet loss of one or more data packets.

[0006] The transmitting device determines the bandwidth of the first data connection based on at least one feedback and a congestion window. More specifically, the transmitting device may determine, based on the feedback, whether a congestion window collapse event has occurred. In one embodiment, a congestion window collapse event may be any event that causes the transmitting device to reduce the congestion window to avoid congestion when the transmitting device further transmits data to the receiving device. Such events may include a packet loss event (for example, due to transmitting too much data over the network) or the RTT of one or more data packets exceeding a threshold. In this case, the collapse event may include reducing the congestion window from a congestion window associated with the collapse event (for example, the most recent one). As a result, the transmitting device may determine the bandwidth based on a congestion window, such as a preceding congestion window before the (most recent) congestion window collapse, and the bandwidth may be based on the transmit rate at which the transmitting device was transmitting data packets according to the preceding congestion window.

[0007] The transmitting device may transmit the bandwidth and / or other determined characteristics related to the first data connection, such as jitter, to the receiving device via a separate data connection for presentation (through a display device). In one embodiment, the transmitting device may terminate the data transmission and / or disconnect the first data connection in response to determining the bandwidth. As a result of determining the bandwidth based on congestion window collapse, the exact maximum transmission rate may be determined by transmitting a minimum amount of data between the transmitting and receiving devices. Unlike conventional testing, for example, in which the receiving device may request the transmitting device to transmit a test data file of a specific size, the present disclosure may produce effective performance results without requiring the transmission of the entire test data file (e.g., only a portion of the file), resulting in less data transmission. Furthermore, the present disclosure enables the performance test to be performed by the transmitting device, which may be a remote server in this case, as opposed to a client device.

[0008] According to another embodiment of the present disclosure, the method is carried out by one or more processors of a receiving device. In particular, the device transmits a request to a transmitting device via a first data connection for the transmitting device to transmit test data for performance testing of the first data connection. In one embodiment, the receiving device may receive a request to perform a test via a user input device, and in response to receiving the request, may establish a first data connection with the transmitting device via a network to perform the performance test. The receiving device may receive a portion of the requested test data from the transmitting device via the first data connection, and may transmit feedback based on the portion of the requested test data via the first data connection. The receiving device may receive a message from the transmitting device via a second data connection, including the data transmission rate of the first data connection based on the portion of the requested test data. In one embodiment, in response to transmitting the feedback, the receiving device receives an instruction from the transmitting device via the first data connection that the first data connection should be disconnected without receiving the remainder of the requested test data. The receiving device may present the data transmission rate by, for example, displaying the rate on a display device.

[0009] The above summary does not constitute an exhaustive list of all embodiments of the Disclosure. The Disclosure is intended to include all systems and methods that can be implemented not only based on all suitable combinations of the various embodiments summarized above, but also on combinations disclosed in the following detailed description and specifically noted in the claims filed with this application. Such combinations have certain advantages not specifically described in the above summary.

[0010] Embodiments of the present disclosure are illustrated in the accompanying drawings, not as limitations, but as examples, where similar reference numerals indicate similar elements. It should be noted that any reference in the present disclosure to “an” or “one” embodiment of the present disclosure does not necessarily refer to the same embodiment, but rather means at least one embodiment. Furthermore, a given drawing may illustrate features of two or more embodiments of the present disclosure, and not all elements in the drawing are required to be present in the given embodiment. [Brief explanation of the drawing]

[0011] [Figure 1] This diagram illustrates a network benchmark system in several embodiments. [Figure 2a] The following are illustrative signal diagrams of the processes performed by a network benchmark system to evaluate data connectivity between transmitting and receiving devices, according to several embodiments. [Figure 2b] The following are illustrative signal diagrams of the processes performed by a network benchmark system to evaluate data connectivity between transmitting and receiving devices, according to several embodiments. [Figure 3] A graph of the congestion window curve according to one embodiment is shown. [Figure 4] This is a flowchart of one embodiment of the process for determining the bandwidth of the data connection between two devices, according to several embodiments. [Modes for carrying out the invention]

[0012] Next, some embodiments of the present disclosure will be described with reference to the accompanying drawings. Whenever an embodiment described herein is not expressly specified, the scope of the present disclosure is not limited to the illustrated portion, and this is for illustrative purposes only. Furthermore, although numerous details are shown, it will be understood that embodiments of the present disclosure may be carried out without these details. In other examples, well-known circuits, structures, and techniques are not shown in detail so as not to obscure the understanding of this specification.

[0013] In this specification, any reference to “one embodiment” or “an embodiment” means that certain features, structures, or characteristics described in relation to that embodiment may be included in at least one embodiment, but not all embodiments necessarily include those particular features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment.

[0014] Figure 1 is a diagram illustrating a network benchmark system (hereinafter referred to as the "System") 10 according to several embodiments. The System 10 includes a receiving device 13, a transmitting device 11, and a network (e.g., the Internet) 12. In one embodiment, the System may include more devices, such as having one or more transmitting devices, each configured to transmit at least some data to the receiving device. In another embodiment, the System 10 may include one or more further devices that may be communicatively connected to the receiving device 13.

[0015] The transmitting device 11 and the receiving device 13 may be any type of electronic device capable of establishing a data connection to another electronic device to exchange data (e.g., data packets) over one or more networks in order to perform performance tests during data connection. For example, the receiving device may be any type of client device such as a tablet computer, desktop computer, mobile device (e.g., smartphone), or media player. In another embodiment, the receiving device may be any type of network device such as a server, router, or hub. The transmitting device may be a network device such as a server.

[0016] In one embodiment, the transmitting device is exemplified as a server and the receiving device as a client device, but either device may be a transmitting or receiving device based on the operation performed by the other device. For example, the “transmitting” device may be any type of device that may be tasked (e.g., by the receiving device) with the task of transmitting (e.g., test) data to determine the characteristics of a data connection established between the transmitting and receiving devices. The “receiving” device may be any type of device that may receive data and / or transmit feedback to the transmitting device. As a result, as described herein, the client device 13 may be a transmitting device that may perform one or more operations of the transmitting device described herein, and the server may be a receiving device. Further description herein is provided regarding the reversal of the roles of the devices.

[0017] The receiving device 13 includes a network interface 81, a controller 82, a memory 83, a speaker 86, a display device 87, and an input device 88. In one embodiment, the receiving device may include more or fewer elements than those described herein. For example, the receiving device may include one or more speakers, a display device, and / or an input device. In another example, the device 13 may not include a speaker, a display device, and / or an input device.

[0018] The network interface 81 provides an interface through which the receiving device 13 communicates with electronic devices such as the transmitting device 11 via the network 12. For example, the network interface may be configured to establish a data connection (e.g., a communication link) with the transmitting device 11 (e.g., the network interface 14 of the transmitting device 11), and once established, to exchange digital data, as described herein. In one embodiment, the network 12 may be any type of computer network, such as a wide area network (WAN) (e.g., the Internet), a local area network (LAN), etc., on which devices may exchange data with each other and / or with one or more other electronic devices. In another embodiment, the network may be a wireless network, such as a wireless local area network (WLAN), a cellular network, etc., on which digital (e.g., test) data is exchanged. With respect to cellular networks, the electronic device 13 may be configured to establish a radio (e.g., cellular) call which may include one or more cellular base stations, which may be any type of communication network (e.g., 4G LTE (Long Term Evolution) network, 5G network, etc.) that supports data transmission (and / or voice calls) for electronic devices such as mobile devices (e.g., smartphones). In one embodiment, the receiving device 13 may be configured to communicate with one or more devices over the network 12 using any type of communication protocol, such as Transmission Control Protocol / Internet Protocol (TCP / IP), QUIC (Quick User Datagram Protocol (UDP) Internet Connection), etc.

[0019] In another embodiment, the devices may be configured to wirelessly exchange data over other networks, such as a Wireless Personal Area Network (WPAN) connection. In an example, the transmitting device 13 may be configured to establish wireless communication with another electronic device via a wireless communication protocol (e.g., the Bluetooth protocol or any other wireless communication protocol). During the established wireless connection, the devices may exchange (e.g., transmit and receive) data packets (e.g., Internet Protocol (IP) packets) containing digital data.

[0020] The input device 88 may be any type of device that is arranged to receive user input. For example, device 88 may include a keyboard, one or more buttons, a mouse, and the like. In another embodiment, device 88 may be part of a display device 87, thereby the display device may be a touch-sensitive display screen that is arranged to receive user input through one or more user touches.

[0021] The controller 82 may be (or may include) a dedicated processor such as an application-specific integrated circuit (ASIC), a general-purpose microprocessor, an FPGA (Field Programmable Gate Array), a digital signal controller, or a set of hardware logic structures (e.g., a filter, an arithmetic logic unit, and a dedicated state machine). The controller may be configured to perform one or more performance test (e.g., evaluation) operations and / or networking operations as described herein. Further descriptions of the operations performed by the controller are provided herein.

[0022] Memory 83 may be any type of non - transitory machine - readable storage medium, such as a read - only memory, a random access memory, a CD - ROM, a DVD, a magnetic tape, an optical data storage device, a flash memory device, and a phase - change memory. Although illustrated as being provided inside device 13, one or more components may be part of a separate electronic device, such as when the memory is a separate data storage device.

[0023] As shown, memory 83 includes one (or one or more) receiver device software programs 85 and an operating system 84. The operating system (OS) 84 may be a software component responsible for managing and coordinating activities and sharing resources of device 13 (such as controller resources, memory, etc.). In one embodiment, the OS serves as a host for application programs (such as program 85) running on device 13. In one embodiment, the OS provides an interface to the hardware layer (such as a controller, memory, etc.) and may include one or more software drivers that communicate with the hardware layer. For example, the driver can receive data packets through the hardware layer from one or more other devices communicatively coupled to the device and process the received data packets. In one embodiment, the OS may include a kernel (or part of a kernel) that provides an interface between one or more programs (such as may be executed by controller 82) and the hardware layer.

[0024] The receiver device software program 85 can be any type of software application that, when executed (e.g., by the controller 82), causes the receiver device 13 to communicate via the network 12 and perform one or more performance test operations (which may include one or more instructions). For example, the program can cause the receiver device to exchange messages with the transmitter device 11 via the network 12 using any type of communication protocol, such as TCP / IP, QUIC, etc. (e.g., Hypertext Transfer Protocol (HTTP), HTTPS, etc.) using any type of communication protocol (e.g., via the network interface 81). In one embodiment, the program 85 can be any application that can interact with a web-based application and perform a performance test. In one embodiment, the software program 85 can be a performance test application that determines one or more connection characteristics, such as bandwidth, when executed by establishing a data connection with one or more devices, such as the transmitter device 11. Specifically, the software program 85 can establish a TCP data connection (or a QUIC connection) with the transmitter device 11 and transmit a request to start a performance test when the connection is established. The transmitter device can transmit data (e.g., test data 80) as described herein. In one embodiment, the program 85 can be configured to access a web browser (e.g., that may be operated by the transmitter device 11) and perform a performance test. In one embodiment, the program can be configured to display a graphical user interface (GUI) on the display device 87 that is arranged to present the characteristics of the performance test, such as bandwidth.

[0025] The transmitting device 11 includes a network interface 14, a controller 15, and memory 16. The memory 16 includes a transmitting device software program 17, congestion control 18, an operating system 19, and test data 80. In one embodiment, the test data may include one or more test data files that may be used to perform the test. In another embodiment, the data may be specifically for use in performance testing. Although illustrated as being stored in the memory of the transmitting device 11, the test data may be stored in a separate storage device and retrieved by the transmitting device when needed. In some embodiments, the test data may be any type of data. For example, the data used for performance testing may be any type of data that may be transmitted from the transmitting device 11 to the device 13, such as data requested by the user (e.g., multimedia content).

[0026] The transmitting device software program 17 may be any type of software program that communicates with one or more devices over a network when executed by the controller 15 and may perform one or more performance test operations as described herein. For example, the software program 17 may be a performance test application (e.g., a web-based application) that may perform one or more data connectivity performance tests when executed by the controller 15 as described herein.

[0027] Congestion control 18 may be any type of application (instruction) that performs congestion control and congestion avoidance during a data connection between a transmitting device 11 and one or more receiving devices in order to provide data packet flow control. In one embodiment, the algorithm may be part of the operating system 19 (e.g., the kernel of the operating system 19). For example, in the case of a TCP data connection, congestion control 18 may be implemented at least partially in the transport layer by the operating system kernel. In another embodiment, congestion control 18 may be performed at least partially by a software application (e.g., a congestion control algorithm) in the application layer. This may be the case when the connection is a QUIC data connection.

[0028] Congestion control 18 may include two main stages in the data connection lifecycle in which the transmitting device 11 may transmit data such as test data 80 to the receiving device 13: a congestion detection stage (or control) and a congestion avoidance stage. In one embodiment, each of the stages may be performed once or multiple times during the duration of the data connection, either by the same algorithm or by different algorithms. For example, the first stage may be performed by the HyStart algorithm, while the second stage may be performed by the CUBIC algorithm.

[0029] During the first stage, i.e., the congestion detection stage, the transmission rate of data packets sent by the transmitting device 11 increases rapidly. In detail, the congestion control may expand the congestion window (or congestion window size) which indicates the amount of data that may be transmitted in any given time. In detail, the congestion window may be a measure of how much data (e.g., how many bytes) may be transmitted over the data connection without acknowledgment. The congestion control 18 may define a congestion window and transmit data according to that window. The congestion control may expand the congestion window at each round-trip time (RTT), for example, when it receives one or more acknowledgments from the receiving device for data previously transmitted during a preceding congestion window. This process may be repeated until a congestion window collapse event occurs, for example, when it receives an acknowledgment for previously transmitted data. In one embodiment, a congestion window collapse event is any event that may cause congestion or data saturation (which would thereby adversely affect communication) within the data connection. Such events may include, for example, a packet loss event. When a packet loss event occurs, it may be determined that the data connection is saturated. Congestion window collapse events are described further in this specification. Thus, the congestion window size may be increased over time until a congestion window collapse event occurs (for example, by doubling the size). In one embodiment, the congestion window before the collapse event may represent the maximum transmit rate or pacing rate (e.g., bytes / second), so that the transmitting device can transmit the maximum amount of data through the data connection without congestion (e.g., without losing data packets).

[0030] When the maximum transmission rate at which a congestion window collapse event occurs is reached, congestion control moves to a second stage, in which it attempts to maintain a transmission rate slightly below the rate at which the congestion window collapse event occurred. Specifically, congestion control shrinks the congestion window to a size preceding the congestion window associated with the collapse event, and then begins to expand the congestion window again until another collapse is detected. In one embodiment, this process may be repeated for the duration or duration of the data connection. Thus, congestion control can be influenced by data connections such as TCP and QUIC, similar to bandwidth convergence mechanisms that determine how fast a device can transmit traffic without data packet loss.

[0031] In one configuration, the transmitting device software program 17 may use information from the congestion control 18 to perform performance tests of the data connection with the receiving device. As described herein, the transmitting device may transmit test data 80 by repeatedly expanding the congestion window and transmitting data to the receiving device according to the expanded congestion window until a congestion window collapse event occurs in the most recently expanded congestion window. As described herein, a congestion window collapse event may result from the RTT associated with one or more data packets in the most recently expanded congestion window exceeding a threshold, indicating that the delay between when the packet is transmitted and when an acknowledgment may be received is too long, or indicating a packet loss event. In this case, the transmitting device software program 17 may determine one or more characteristics of the data connection based on the congestion window collapse event (for example, in response). For example, the software program 17 may poll the kernel of the operating system 19 to determine the transmission rate at which data was sent to the receiving device. In another embodiment, this information may be known (determined) by congestion control 18, which may include a congestion control algorithm running at the top level of the operating system. In one embodiment, the transmission rate may be related to (or correspond to) the bandwidth (or data transfer rate) of the data connection. Further characteristics are described herein.

[0032] In another embodiment, the transmitting device software program 17 may determine characteristics of the data connection, such as the bandwidth, based on the data connection information. In an example, the software program 17 may determine the congestion window prior to the most recent expanded congestion window associated with a collapse event, and the RTT associated with the previous congestion window, which may be obtained from congestion control (and / or the kernel of the operating system 19). The software program may determine the bandwidth, or the transfer rate, which may be given by the following equation: Data transfer rate = congestion window / round-time time (RTT)

[0033] In the formula, the congestion window may be a previous congestion window to which collapse events and RTT may be associated. Further details regarding how software programs use congestion control to determine bandwidth are provided herein.

[0034] Figures 2a and 2b illustrate signal diagrams of processes 20 performed by the network benchmark system 10 to evaluate the data connection between the transmitting device 11 and the receiving device 13, according to several embodiments. In detail, at least some of the operations described herein may be performed by either of the devices. For example, at least some operations may be performed by the controller 82 of the receiving device (which may perform, e.g., the receiving device software program 85), and / or at least some operations may be performed by the controller 15 of the transmitting device 11 (which may perform, e.g., the transmitting device software program 17 and / or congestion control 18).

[0035] Returning to Figure 2a, process 20 begins (in block 21) when the controller 82 of the receiving device 13 receives an input to perform a data connection performance test. More specifically, the request may be a user request that the device software program 85 may receive via the input device 88. For example, the software program may be configured to display a graphical user interface (GUI) on the display device 87, which may include one or more user interface (UI) items that the user may select through the input device. In this case, the GUI may include a UI item for initiating a performance test, and the UI may be selected by the user (for example, by selecting an item on the display device, which may be a touch-sensitive display screen, as described herein).

[0036] The controller 82 may have the receiving device 13 transmit a request to perform a performance test of a first data connection to the transmitting device 13. For example, the request may be a message using any type of communication protocol, such as HTTPS, which may be transmitted over an existing data connection (e.g., TCP connection, QUIC connection, etc.) with the transmitting device 11 that may be established. In one embodiment, the message may include an instruction for the transmitting device to initiate one or more performance tests to evaluate the existing data connection. For example, the message may request data (e.g., a specific data file) of a specific size (e.g., a certain number of bytes). In another embodiment, if an existing data connection has not been established, the receiving device may initiate and create a first data connection with the transmitting device to maximize the rate at which the transmitting device transmits data, as described herein. Once established, the receiving device 13 may transmit a performance test request to the transmitting device 11.

[0037] The transmitting device 11 receives a request from the receiving device 13 to perform a performance test of the first data connection. In one embodiment, in response to the request, the transmitting device determines, for example, what data and / or how much data should be transmitted to the receiving device. For example, the request may indicate a request for test data 80 and the amount of data to be transmitted, as described herein. More specifically, the request may indicate that a data file (for example, of a certain size) of the test data 80 should be transmitted to the receiving device.

[0038] In one embodiment, the controller 15 may perform congestion control 18 to initiate and control the flow of data to be transmitted to the receiving device 13 via the first data connection. For example, the controller 15 may perform at least some of the operations described in blocks 22, 24, and 26 and / or decision blocks 23 and 25 during the first and second stages of congestion control, as described herein. In detail, the controller 15 determines a congestion window (CWND) of a specific size (in block 22). In detail, the controller 15 may determine an initial (or initiation) congestion window for transmitting a small amount of data (e.g., test data 80) as one or more data packets (e.g., IP packets). In one embodiment, the initial congestion window may be predetermined. The controller 15 may cause the transmitting device 11 to transmit data (e.g., requested by the receiving device) via the first data connection according to the determined congestion window.

[0039] As described herein, a request received from the receiving device 13 may indicate that a file should be transmitted for a requested performance test. In this case, the controller 15 of the transmitting device may determine that it should transmit a (e.g., test) data file to the receiving device for a performance test (e.g., based on the request). More specifically, the request may indicate that one or more files of test data 80 should be transmitted over a first data connection. Based on the determined congestion window, the controller may determine which portion of the data file should be transmitted. More specifically, the congestion window may indicate that a certain amount of data should be transmitted, and in response, the controller may divide the amount of data obtained from the data file into one or more data packets for transmission.

[0040] The receiving device 13 may receive at least some of the transmitted data via the first data connection and may transmit feedback to the transmitting device via the first data connection based on the received data. In one embodiment, the feedback may include one or more acknowledgments indicating that the receiving device 13 has received one or more data packets transmitted by the transmitting device 11. In another embodiment, the feedback may include an indication of a packet loss event in which at least one transmitted data packet was lost. For example, the feedback may include one or more duplicate acknowledgments related to one or more data packets that may indicate packet loss. In another embodiment, the feedback may include only a subset of acknowledgments for a set of data packets transmitted by the transmitting device 11 (e.g., fewer acknowledgments than a set of data packets).

[0041] The transmitting device 11 may receive feedback from the receiving device 13, and the controller 15 of the transmitting device 11 may, based on the feedback (in the decision block 23), determine whether a congestion window collapse event has occurred. For example, the controller 15 may determine whether a packet loss event has occurred. In one embodiment, the controller 15 may make this determination based on whether it has received one or more (e.g., three) duplicate acknowledgments from the receiving device 13. In another embodiment, this determination may be made based on whether the feedback has omitted one or more acknowledgments for one or more data packets transmitted by the transmitting device. In another embodiment, the collapse event may be determined based on one or more acknowledgments that took too long for the transmitting device to receive. For example, the transmitting device may determine the round-trip time (RTT) based on the transmission of one or more data packets and the reception of one or more corresponding acknowledgments from the feedback. The controller 15 may determine whether there is a delay in the transmission path that may indicate congestion. In detail, the controller may determine that a congestion window collapse has occurred when one or more RTTs associated with one or more data packets exceed a threshold (e.g., a predefined threshold).

[0042] If the threshold is not exceeded, the controller 15 continues to expand the congestion window (in block 24). The controller may expand the congestion window by one or more maximum segment sizes (MSS) (for example, by addition or multiplication). For example, if the congestion window is 1 MSS, the controller may add 1 MSS to the congestion window, effectively doubling the number of data packets that the transmitting device 11 may transmit. The controller 15 then causes the transmitting device to transmit data according to the expanded congestion window.

[0043] In one embodiment, the controller 15 may iteratively expand the congestion window and transmit data through the first data connection according to the expanded congestion window until a congestion window collapse event occurs in the most recent expanded congestion window. In this case, the controller 15 of the transmitting device may flood the data connection with the receiving device until packet loss is present or sufficient delay is present within the data path, as described herein. In this case, the transmitting device may saturate the first data connection with data, thereby providing insight into the maximum data transfer rate from the transmitting device to the receiving device over the first data connection.

[0044] If a congestion window collapse event exists in the decision block 23, the controller 15 may then determine (in the decision block 25) whether there were one or more congestion window collapse events that exceeded a threshold. As described herein, the congestion control 18 may perform at least one or more of these actions between both stages of the congestion control process in order to manage the flow of data. To do so, the control 18 may go back and forth between both stages (or perform one or more of the stages, such as a second stage) while the data connection is ongoing in order to achieve maximum processing capacity. As a result, the transmitting device may encounter one or more congestion window collapses while transmitting data to the receiving device 13. As a result, the controller 15 may determine whether it has encountered several events that exceeded a threshold. If it has not, the controller shrinks the expanded congestion window (for example, the expanded latest congestion window related to the most recent congestion window collapse event) and then transmits the data according to the shrunken congestion window. In that case, the controller may perform a second stage of congestion control, in which the congestion window is reduced, data is transmitted to the receiving device 13 according to the reduced congestion window, and the window may then be expanded (in block 24) based on a determination of whether a congestion window collapse event has occurred in the reduced window. In one embodiment, the controller 15 may perform at least some of these congestion control operations until several detected congestion window collapse events occur. If several detected congestion window collapse events have occurred, the process 20 may proceed to Figure 2b.

[0045] In one embodiment, one or more operations described herein may be optional. In particular, the operations of decision blocks 25 and 26 may be optional, and as a result, if a congestion window collapse event (e.g., a first one) is detected, the controller 15 may proceed to Figure 2b. Specifically, the controller 15 may perform the first stage of the congestion control algorithm, thereby expanding the congestion window until a congestion window collapse event occurs. However, upon detecting the event, the controller 15 proceeds through process 20, omitting the optional operations described herein (e.g., shrinking the expanded congestion window to continue data transmission). This may reduce the amount of data to be transmitted over the first data connection.

[0046] Next, looking at Figure 2b, the transmitting device's controller 15 (in block 27) determines one or more characteristics of the first data connection, such as the bandwidth, based on one or more congestion window collapse events. More specifically, the transmitting device may determine the characteristics based on the determination that one or more congestion window collapse events have occurred. More specifically, the controller 15 may determine characteristics such as bandwidth in response to receiving a packet loss event instruction or determining that one or more RTTs have exceeded a threshold. In a practical example, when the transmitting device transmits one or more data packets according to a congestion window, the controller 15 may poll the operating system 19 (e.g., the kernel of the operating system 19) to obtain socket information, such as the congestion window at the time of the collapse event or the congestion window prior to the collapse event, and the pacing (e.g., data transmission) rate, which the kernel considers to be a safe transmission rate of bytes / second without congestion over the data connection. More specifically, the controller may determine the rate at which to transmit data to the receiving device based on (or in relation to) the congestion window prior to the most recent congestion window associated with the congestion collapse event. In another embodiment, the controller 15 may determine other characteristics related to the previous congestion window, such as RTT for at least one data packet, jitter for one or more data packets, or packet loss for one or more data packets (for example, related to the congestion window prior to the collapse event). In another embodiment, the controller may determine the amount of data transmitted to the receiving device.

[0047] In one embodiment, the controller 15 may determine characteristics based on a number of congestion window collapse events. As described herein, the controller 15 may perform congestion control until a number of congestion window collapse events occur (for example, until the number of events exceeds a threshold). In this case, the controller may determine characteristics associated with each (or at least some) of the events (e.g., socket information polling). In detail, data may be polled during or in relation to congestion windows preceding or related to the window associated with a collapse event. As a result, the controller may determine characteristics based on socket information related to at least some of the collapse events. For example, the controller may determine bandwidth as the average (or median) of pacing rates polled from the kernel at least some of the collapse events prior to the collapse events. Thus, the controller 15 may determine characteristics based on information related to each collapse, which may provide a better description of the data connections between devices.

[0048] The controller 15 finishes transmitting the data (for example, by having the transmitting device finish) in block 28. More specifically, once the transmitting device has determined its characteristics, it may stop transmitting data over the first data connection. In this way, the transmitting device 11 may complete the performance test by transmitting only a portion of the data (of the data file) requested by the receiving device 13. In that case, in response to receiving feedback, the transmitting device may finish transmitting the remainder of the data file requested by the receiving device to the receiving device over the first data connection. As a result, the system 10 may use dramatically less data (for example, less than 10%) than would be used during a conventional performance test if the transmission were not completed. The controller 15 may disconnect the first data connection (in block 29). For example, when the devices are connected via a TCP connection, the transmitting device 13 may transmit a message (for example, containing "FIN") over the connection, and in response to receiving it, the receiving device 13 may transmit an acknowledgment, after which the connection may be terminated. In one embodiment, the controller may disconnect the first data connection between the two devices in response to determining one or more characteristics of the first data connection (e.g., bandwidth).

[0049] Thus, in response to one or more congestion window collapse events, the transmitter's controller 15 may be configured to determine characteristics, terminate data transmission, and disconnect the connection. Blocks 28 and 29 are illustrated as separate blocks, but their operations may be performed together. In detail, the transmitter 11 may terminate data transmission by disconnecting the first data connection. In this case, the transmitter 11 may transmit a FIN message, as described herein, thereby stopping the transmission of the test data 80, as described herein. As a result, in response to transmitting feedback, the receiver may receive instructions from the transmitter to disconnect the first data connection without receiving all of the requested test data (e.g., the remainder of the requested test data) via the first data connection (e.g., by receiving the FIN message).

[0050] As described above, the controller 15 may determine whether a congestion window collapse event has occurred based on feedback from the receiving device. In one embodiment, the controller may determine whether a congestion window collapse event has occurred based on whether congestion control at the transmitting device (for example, in block 26) has reduced the congestion window. More specifically, one or more software applications and / or the kernel of the operating system 19 may perform one or more of the operations described herein to determine, for example, whether the congestion window should be reduced due to a packet loss event. The controller may poll the kernel while data is being transmitted to the receiving device to determine whether the congestion window has been reduced. In response, the controller may determine that a congestion window collapse event has occurred and may poll the kernel to obtain one or more characteristics as described herein. More specifically, the controller may determine the pacing rate at which the data was transmitted before the collapse, as described herein. This may be the case when the connection is a TCP connection. In another embodiment, the controller may poll one or more software applications that are performing congestion control when the data connection is a different type of connection, such as a QUIC connection.

[0051] The transmitting device 11 transmits one or more determined characteristics over a second data connection. More specifically, the transmitting device transmits a message to be received by the receiving device, including characteristics such as the data transmission rate of the first data connection based on a portion of the requested test data. In one embodiment, the transmitting device 11 may store characteristics such as pacing rate and deliver the characteristics to the receiving device out of band. For example, the transmitting device may establish another (e.g., TCP) data connection and transmit characteristics over that connection. In one embodiment, the transmitting device may transmit bandwidth (or pacing rate) over that data connection. In another embodiment, the transmitting device may transmit yet another characteristic of the first data connection over the second data connection, such as one or more RTT, jitter, packet loss indications related to congestion windows, and the total amount of data transmitted over the first data connection.

[0052] In one embodiment, the transmitting device 11 may transmit one or more characteristics through any type of electronic message. For example, the transmitting device may transmit the characteristics as an electronic message using any type of protocol, such as SMTP (Simple Mail Transfer Protocol). In another embodiment, the characteristics may be transmitted as a push notification in the form of a message (e.g., SMS).

[0053] The receiving device 13 receives one or more characteristics through the second data connection. The controller 82 presents one or more characteristics (in block 51). For example, the receiving device software program 85 may display the characteristics within a GUI in the display device 87. In detail, the controller may display the pacing speed as the bandwidth of the first data connection on which the performance test was performed. In another embodiment, the software program may output sound through the speaker 86, including an audible representation of the characteristics, such as an output sound including "Your internet speed is 500 megabits per second."

[0054] As described herein, congestion control 18 may be part of the operating system 19 (e.g., the kernel) or a software application. In one embodiment, congestion control operations may be performed by the kernel when the data connection is a TCP connection, while at least some of the operations may be performed at the application layer when the data connection is another type of connection, such as a QUIC connection. As a result, at least some of the operations, such as bandwidth determination as described in block 27, may be performed by one or more software applications running on one or more processors of the transmitting device (e.g., congestion control algorithms running at the top level of the operating system).

[0055] The process 20 described herein provides an accurate and efficient method for a transmitting device 11 to measure the bandwidth of a first data connection with a receiving device 13. Unlike conventional performance tests performed on the receiving side, this disclosure provides an example of a performance test performed on the transmitting side. In conventional tests, a common concern with measurements on the transmitting side is the complete lack of knowledge as to whether the data actually reached the receiving side, and the data may end up being buffered in a buffer. This is especially true when an application instructs the transport layer (e.g., TCP) to write data into a socket, and then transfers the data asynchronously. However, this disclosure solves this problem by tracking transmitted data, for example, by using a congestion algorithm that the kernel of the transmitting device may perform. Specifically, the congestion control algorithm may track acknowledgments for each segment (data packet) sent to the receiving device 13 and, based on feedback received from the receiving device, may constantly consider and evaluate the rate at which the segment is being delivered to its final destination. In this case, the transmitting device does not transmit more than the congestion window defined by the congestion control that would be possible without receiving an acknowledgment. As a result, system 10 may perform accurate performance tests based on congestion control that depends on acknowledgments received from the receiving equipment, thereby minimizing (or eliminating) any buffering effects.

[0056] Figure 3 shows a graph 30 of a congestion window curve 31 according to one embodiment. The congestion window curve 31 represents the size of the congestion window against time, which is exemplified as RTT. In detail, the curve represents the change in the congestion window due to congestion control 18 while one or both congestion control stages are being performed. In one embodiment, the curve represents the window between at least some of the operations performed in blocks 22-26 of process 20, as described in Figure 2a.

[0057] At time = 0, congestion control 18 determines and sets an initial congestion window (CWND0), thereby causing the transmitting device 11 to transmit one or more data packets of data according to CWND0. Congestion control waits to receive one or more acknowledgments from the receiving device 13 for one or more data packets, thereby indicating that no congestion window collapse events have occurred. Upon receiving all (or at least some) acknowledgments at RTT1, congestion control 18 expands the congestion window to CWND1. This process (e.g., optional blocks 23 and 24 of process 20 in Figure 2a) is repeated for two additional time intervals, as illustrated. In detail, the controller performs one or more congestion control algorithms to expand the congestion window indicating the number of data packets to transmit and transmit data packets according to the expanded window. Thus, the transmitting device begins transmitting data, and the rate of data transmission increases per round-trip time without congestion by expanding the congestion window (e.g., doubling). In one embodiment, this expansion may be additive or multiplicative. In one embodiment, this expansion may be exponential.

[0058] However, at CWND3, congestion control 18 detects a congestion window collapse event 32. More specifically, the congestion control algorithm determines, based on feedback from the receiving equipment, whether a congestion window collapse event has occurred in the expanded congestion window. For example, the transmitting equipment may receive feedback from the receiver indicating packet loss (e.g., duplicate acknowledgments), or congestion control may determine that one or more RTTs for one or more received acknowledgments have significant delays (e.g., exceeding a threshold). At this point, the transmitting equipment may assume that it has achieved the maximum transmit rate of the connection (e.g., no packet loss and / or excessive delays at all). In that case, it shrinks the congestion window at RTT3 to avoid congestion. From RTT3 to RTT6, congestion control may continue to expand the congestion window until it detects another congestion window collapse event, thereby then shrinking the congestion window again.

[0059] In one embodiment, the length (e.g., duration) of the curve 31 may be based on several congestion window collapse events used by the controller 15 measuring the characteristics of the data connection. For example, if the characteristics are measured until only one collapse event is detected, the curve may end at RTT3. At that point, the controller 15 may poll the congestion control 18 and / or the kernel of the transmitting device to obtain information. For example, in response to determining that a congestion window collapse event has occurred, the congestion control algorithm may shrink the expanded congestion window and / or poll (e.g., the kernel of the transmitting device 11) to determine one or more characteristics related to the congestion window preceding the detected collapse, which in this case is CWND2, such as the pacing rate of the data connection associated with that congestion window, RTT2, etc., since in this case CWND2 is related to the maximum amount of data that may be transmitted before the collapse event occurs. The transmitting device may immediately store this information as described herein and close (disconnect) the data connection with the receiving device and / or transmit the information to the receiving device 13.

[0060] However, if the previous RTT3 is continued, the controller 15 may poll socket information and continue to expand congestion control until another congestion window collapse event occurs, as shown in RTT3 to RTT6. At that point, the controller 15 may determine (for example, in the decision block 25 of process 20 in Figure 2a) whether a sufficient number of congestion window collapse events have occurred. If so, the controller may determine the characteristics of the data connection based on the information associated with (or preceding) each congestion window collapse event.

[0061] Figure 4 is a flowchart of one embodiment of a process 40 that determines the bandwidth of a data connection between two devices, according to several embodiments. At least some of the operations may be performed by the system 10 to determine one or more characteristics of the data connection between at least two devices, such as bandwidth. In detail, at least some of the operations may be performed by the controller 15 of the transmitting (e.g., first electronic) device 11. The process 40 begins with the controller 15 receiving a request from the second electronic device (e.g., receiving device 13) to perform a performance test of a first data connection (e.g., a TCP connection or a QUIC connection) between the first electronic device and the second electronic device (in block 41). The controller 15 transmits the test data to the second electronic device via the first data connection (in block 42) according to a congestion window. In detail, the controller 15 may cause the first electronic device to transmit the data (e.g., through a network interface 14).

[0062] Controller 15 receives feedback from a second electronic device (in block 43) (for example, via network interface 14) based on at least a portion of the transmitted test data. In detail, the receiving device may transmit the feedback through the first data connection. Controller 15 determines the bandwidth (and / or other characteristics) of the first data connection (in block 44) based on the feedback and congestion window. For example, the feedback from Controller 15 may include an acknowledgment that the receiving device has received one or more data packets, and the RTT may be determined from the acknowledgment. In this case, the controller may determine the bandwidth as the maximum transfer rate based on the difference between the congestion window and the RTT. In another embodiment, the controller may determine the bandwidth (for example, as the pacing rate at which the transmitting device transmitted data) by polling socket information, as described herein. Controller 15 may transmit the bandwidth to the second electronic device (in block 45) via the second data connection. As described herein, the second electronic device may display the bandwidth on the display device 87.

[0063] As described above, performance test operations may be performed by the transmitting device to measure characteristics such as the bandwidth of the data connection with the receiving device. In this case, from the perspective of the receiving device, the bandwidth may represent the internet download speed of the established data connection. As a result, the roles of the devices described herein may be swapped with those of the receiving device 13 in order to determine the internet upload speed of the established data connection. For example, if the transmitting device determines one or more characteristics of the first data connection by transmitting a data stop rather than disconnecting the first data connection in block 29 of processing 20, then both devices may swap roles so that device 13 measures the bandwidth of the first data connection by having device 11 transmit data. In this case, the system may determine the maximum data transfer rate between both devices and present the rate to the user of the client device, so that the maximum data transfer rate determined by server 11 (acting as the transmitting device) may be the internet download speed of the data connection, and the maximum data transfer rate determined by client device 13 (acting as the transmitting device) may be the internet upload speed of the data connection.

[0064] In another embodiment, to measure the internet upload speed of device 13, the device may establish an entirely new data connection and perform the operations described herein. For example, if device 11 disconnects the initial data connection, device 13 may transmit a request to perform a performance test of another data connection. In that case, measuring the characteristics of the new data connection, device 13 may present at least some of the characteristics, as described herein. As a result, system 10 may be able to measure the internet download speed and internet upload speed of device 13 with the minimum amount of data exchanged with device 11.

[0065] As previously described, embodiments of the present disclosure may be a non-temporary machine-readable medium (such as a miniature electronic memory) that stores instructions for programming one or more data processing components (collectively referred to herein as “processors”) to perform at least some of the operations described herein. In other embodiments, some of these operations may be performed by specific hardware components comprising wired logic circuits. These operations may instead be performed by any combination of programmed data processing components and fixed wired circuit components.

[0066] To assist the Patent Office and any reader of any patent issued in this application in interpreting the claims attached herein, the applicants wish to note that none of the attached claims or claim elements are intended to cause the Patent Office or their readers to refer to Section 112(f) of the United States Patent Act unless the terms “means for” or “steps for” are expressly used in the claims.

[0067] While certain embodiments have been described and illustrated with the accompanying drawings, it should be understood that such embodiments are merely illustrative of the broader disclosure and are not limiting to the broader disclosure, and that various other modifications may be conceived by those skilled in the art. Therefore, this disclosure is not limited to the specific configurations and arrangements shown and described.

[0068] In some embodiments, this disclosure may include the phrase, for example, "[Element A] and [Element B]." This phrase may refer to one or more elements. For example, "at least one of A and B" may refer to "A," "B," or "A and B." Specifically, "at least one of A and B" may refer to "at least one A and at least one B," or "at least one of A or B." In some embodiments, this disclosure may include the phrase, for example, "[Element A], 'Element B', and / or 'Element C'." This phrase may refer to any of the elements or any combination of elements. In practice, "A, B, and / or C" may refer to "A," "B," "C," "A and B," "A and C," "B and C," or "A, B, and C."

Claims

1. A method performed by one or more processors of a first electronic device, The steps include receiving a request from a second electronic device to perform a performance test of the first data connection between the first electronic device and the second electronic device, The steps include transmitting test data to the second electronic device via the first data connection according to the congestion window, The steps include receiving feedback from the second electronic device based on at least a portion of the transmitted test data, A step of determining the bandwidth of the first data connection based on the feedback and the congestion window, The steps include transmitting the bandwidth to the second electronic device via a second data connection and A method for providing this.

2. The step further comprises determining one or more characteristics of the first data connection based on the feedback, The aforementioned test data is transmitted as multiple data packets. The one or more characteristics are transmitted to the second electronic device via the second data connection and include the round-trip time of at least one data packet, the jitter of at least one data packet, or the packet loss of one or more data packets. The method according to claim 1.

3. The method according to claim 1, further comprising the step of disconnecting the first data connection between the first electronic device and the second electronic device in response to determining the bandwidth.

4. The method according to claim 1, wherein the first data connection is a Transmission Control Protocol (TCP) connection.

5. The method according to claim 1, wherein the first data connection is a QUIC (Quick User Datagram Protocol (UDP) Internet Connection) connection.

6. The aforementioned test data is transmitted as multiple data packets, and the feedback is, An indication of a packet loss event in which at least one transmitted data packet was lost, or Acknowledgment that the second electronic device has received one or more of the data packets. Equipped with, The method further comprises the step of determining the round-trip time (RTT) between the transmission of one or more data packets and the reception of the acknowledgment. The method according to claim 1.

7. The method according to claim 6, wherein the bandwidth is determined in response to receiving the instruction for the packet loss event or determining that the RTT exceeds a threshold.

8. The step of transmitting the test data comprises repeatedly: expanding the congestion window; and transmitting the test data to the second electronic device via the first data connection according to the expanded congestion window until a congestion window collapse event occurs in the latest expanded congestion window, where the RTT associated with the latest expanded congestion window exceeds a threshold, or until an instruction for the packet loss event is received based on the feedback. The bandwidth is determined based on the congestion window prior to the most recent expanded congestion window, and the RTT associated with the previous congestion window. The method according to claim 6.

9. The steps include determining that a test data file should be transmitted to the second electronic device for the performance test, The steps include determining the test data as part of the test data file based on the congestion window, In response to receiving the aforementioned feedback, the steps include: completing the transmission of the remainder of the test data file to the second electronic device via the first data connection; The method according to claim 1, further comprising:

10. The method according to claim 1, wherein the first electronic device is a server and the second electronic device is a client device.

11. It is a system, At least one processor, When the at least one processor is running, the system The electronic device receives a request to perform a performance test of the first data connection via the first data connection. The electronic device is instructed to transmit the test data as multiple data packets via the first data connection. The electronic device receives feedback based on at least a portion of the transmitted data packets via the first data connection. Based on the feedback and the test data, the data transmission speed of the first data connection is determined. In response to determining the aforementioned data transmission speed, After the transmission of the aforementioned test data is completed, The data transmission rate is transmitted to the electronic device via the second data connection. The memory that stores the instructions inside A system equipped with these features.

12. The system according to claim 11, wherein the plurality of data packets are a portion of the test data, and the command that completes the transmission of the test data includes a command that disconnects the first data connection between the system and the electronic device without transmitting the remainder of the test data.

13. The system according to claim 12, wherein the request comprises a request for the system to transmit all of the test data.

14. The memory executes a congestion control algorithm, Expand the congestion window that shows the number of data packets for transmission. Based on the aforementioned feedback, determine whether a congestion window collapse event has occurred in the expanded congestion window. In response to the determination that the aforementioned congestion window collapse event has occurred, The aforementioned enlarged congestion window is reduced, The data transmission rate is determined using the number of data packets in the congestion window. The system according to claim 11, having other commands.

15. The step of determining whether the aforementioned congestion window collapse event has occurred is based on the feedback, A packet loss event occurred, or The round-trip time (RTT) of one or more data packets exceeds the threshold. The system according to claim 14, further comprising the step of determining whether or not.

16. The system according to claim 11, wherein the memory further includes instructions for determining one or more further characteristics of the first data connection based on the feedback, the one or more further characteristics comprising the round-trip time of at least one data packet, the jitter of the at least one data packet, or the packet loss of one or more data packets.

17. The system according to claim 11, wherein the first data connection is a Transmission Control Protocol (TCP) connection or a QUIC (Quick User Datagram Protocol (UDP) Internet Connection) connection.

18. A method performed by one or more processors of a receiving device, The steps include transmitting a request to a transmitting device via a first data connection that the transmitting device transmit test data for performance testing of the first data connection, The steps include receiving a portion of the requested test data from the transmitting device via the first data connection, The steps include transmitting feedback based on the requested portion of the test data to the transmitting device via the first data connection, The steps include receiving a message from the transmitting device via a second data connection, which includes the data transmission rate of the first data connection based on the portion of the requested test data, The steps include: presenting the data transmission speed and A method for providing this.

19. The steps include receiving a request to perform the performance test via a user input device, In response to receiving the aforementioned request, the first data connection with the transmitting device is established via the network to perform the performance test. The method according to claim 18, further comprising:

20. The method of claim 18, further comprising the step of receiving an instruction from the transmitting device via the first data connection that, in response to the transmission of the feedback, the first data connection should be disconnected without receiving the remainder of the requested test data.

21. The method according to claim 18, wherein the receiving device is a mobile device.

Images