Reduction of Network Congestion

CROSS-REFERENCE TO RELATED APPLICATION

0001This application claims the benefit of U.S. provisional patent application Ser. No. 61/980,476, filed Apr. 16, 2014, titled “Apparatus, System, and Method for Reducing Network Congestion,” the entirety of which is incorporated by reference herein.

BACKGROUND

0002Communications across computer networks have become a widely available form of communications. The communications can be between many forms of computing devices, including: mobile devices, servers, clients to servers, game consoles, desktop computers, laptops and a myriad of other computing devices. The form of data being sent in these communications usually takes the form of packets that are transmitted between the computing devices.

0003Data may be transmitted through the internet using packets or chunks of information. Packet formatting and the method for delivering packets across the internet are governed by the protocol known as TCP/IP (transmission control protocol/internet protocol). For a TCP data transmission to be completed, the recipient TCP layer may collect the packets and organize the packets in the order in which the packets were sent. If a packet is lost, the protocol interprets this as a sign that the network is congested—the transmission speed is immediately halved, and from there the packets speed attempts to increase again at a slow rate. This is beneficial in some situations and inefficient in other situation. Unfortunately, TCP the protocol does not have the intelligence to know how to otherwise address problems in network congestion.

BRIEF DESCRIPTION OF THE DRAWINGS

0004<figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram illustrating an example of a system for managing congestion in a computer network in a client-to-server configuration.

0005<figref idref="DRAWINGS">FIG. 1B</figref> is a block diagram illustrating an additional example of a system for managing congestion in a computer network in a node-to-node configuration.

0006<figref idref="DRAWINGS">FIG. 1C</figref> is a block diagram illustrating an example of a system for managing congestion in a computer network in a client-to-server configuration utilizing wireless networking and communication.

0007<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an example of details of a congestion management apparatus.

0008<figref idref="DRAWINGS">FIG. 3</figref> is block diagram illustrating an example of a congestion management apparatus with a data traffic analysis module.

0009<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating an example of checking a data loss range against a threshold to determine whether to apply RLNC (random linear network coding).

0010<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating an example of checking a data loss range against two thresholds to determine whether to apply RLNC (random linear network coding).

0011<figref idref="DRAWINGS">FIG. 6</figref> is block diagram illustrating an example of a computing device for reducing network congestion through selective use of RLNC (random linear network coding) encoding.

DETAILED DESCRIPTION

0012A technology is provided for reducing network congestion through selective use of RLNC (random linear network coding) encoding. A data loss rate pertaining to a datastream between a client and a server may be determined. The datastream may comprise data packets sent and received between the client and the server. The client and the server may send and receive data packets to and from each other, which are encoded using random linear network coding (RLNC) in response to determining that the data loss rate is higher than or equal to a first threshold.

0013<figref idref="DRAWINGS">FIG. 1A</figref> is a schematic block diagram illustrating one high level configuration of a system for reducing network congestion through the use of random linear network coding. The system <b>100</b> includes a server <b>102</b> with a congestion management apparatus <b>104</b> (e.g., a congestion management module controlled and/or executed by at least one processor device) connected to multiple clients <b>106</b><i>a</i>-<i>c </i>(collectively, <b>106</b>) through a network <b>110</b>, and a database <b>108</b>, which are described further below.

0014The system <b>100</b> includes clients <b>106</b><i>a</i>-<i>c </i>in communication with a server <b>102</b> having a congestion management apparatus <b>104</b> through a network <b>110</b>. The server <b>102</b> may be any computer accessible by a client <b>106</b> over a network <b>110</b>, including but not limited to a gateway, router, mainframe server, or proxy server. For example, the server <b>102</b> can be a gateway that connects the client <b>106</b> to the Internet, cloud-based servers, or another client <b>106</b>. The network <b>110</b> connecting the server <b>102</b> and the client <b>106</b> may include a local area network (“LAN”), a wide area network (“WAN”), a wireless network, a cellular network, the internet, or the like. The database <b>108</b> may be any form of data storage, including but not limited to a relational database or a flat file. The database <b>108</b> can be hosted on the server <b>102</b> or a separate server. The congestion management apparatus <b>104</b> may reside solely on server <b>102</b> or may be spread across several servers. In one embodiment, the congestion management apparatus <b>104</b> resides in part on the server <b>102</b> and in part on the client <b>106</b>. In another embodiment, the congestion management apparatus <b>104</b> resides in part on the server, in part on the client <b>106</b>, and also in part on a different server hosting the database <b>108</b>. The congestion management apparatus <b>104</b> is described in more detail with respect to the apparatus <b>200</b> in <figref idref="DRAWINGS">FIG. 2</figref>.

0015The client <b>106</b> may be an electronic device or a software application running on a electronic device (e.g., a mobile electronic device). The client(s) <b>106</b><i>a</i>-<i>c </i>as an electronic device may be a smartphone, a tablet computer, a laptop computer, a desktop computer, mobile device, a server, a digital media player (e.g., Apple TV), a network appliance, a gaming console (e.g., PlayStation, Xbox, Wii) or the like. The client <b>106</b> as a software application may include a VPN (virtual private network) client and/or an application running on a mobile electronic device.

0016The client <b>106</b> is capable of encoding data packets using random linear network coding and is capable of sending and receiving these data packets, as well as receiving and decoding data packets encoded using random linear network coding. Random linear network coding enables (i) a receiver (e.g., the server <b>102</b> or the client <b>106</b>) to ignore lost data packets sent by the transmitter (e.g., the server <b>102</b> or the client <b>106</b>) and acknowledge the receipt of certain data packets and (ii) a transmitter to avoid retransmitting data packets, thus reducing network congestion, and is explained further below with respect to <figref idref="DRAWINGS">FIG. 2</figref>.

0017<figref idref="DRAWINGS">FIG. 1B</figref> is a schematic block diagram illustrating an additional high level configuration of a system for reducing network congestion through the use of random linear network coding in a node-to-node configuration. The system <b>155</b> includes a congestion management apparatus <b>104</b> (e.g., a congestion management module), multiple nodes <b>150</b><i>a</i>-<i>n </i>(collectively, <b>150</b>), a network <b>110</b>, and the database <b>108</b>. In one embodiment, the congestion management apparatus <b>104</b> may include and/or be controlled by at least one processor device and memory device. The congestion management apparatus <b>104</b> may reside solely on at least one node <b>150</b>, such as node <b>150</b><i>n, </i>or may be spread across several nodes <b>150</b><i>a</i>-<i>c. </i>The congestion management module and each of the multiple nodes <b>150</b><i>a</i>-<i>c </i>may be connected to each other through the network <b>110</b>. In one embodiment, the network <b>110</b> may include wireless networking and communication using one or more wireless communication configurations. For example, the node <b>150</b><i>a </i>may communicate with the congestion management apparatus <b>104</b> on node <b>150</b><i>n, </i>and also the database <b>108</b>, via the network <b>110</b> using wireless communication and devices, such as a WiFi device, Bluetooth device, a wireless router, a wireless modem, or another wireless device.

0018In one embodiment, each of the nodes <b>150</b> may be a similar computing device and/or one or more of the nodes <b>150</b> may different computing devices. For example, each of the nodes <b>150</b> may be a smart phone. Alternatively, for example, node <b>150</b><i>n </i>may be a smart phone, node <b>150</b><i>a </i>may be a computing tablet device, node <b>150</b><i>b </i>may be a laptop computer, and/or node <b>150</b><i>c </i>may be a personal computer, or another type of computing system or device.

0019<figref idref="DRAWINGS">FIG. 1C</figref> is a schematic block diagram illustrating an alternative high level configuration of a system for reducing network congestion through the use of random linear network coding in communications between a wireless networking device <b>174</b> and a client <b>106</b><i>a. </i>For example, the wireless networking device <b>174</b> may be a WiFi device, Bluetooth device, a wireless router, a wireless modem, or another wireless device. The system <b>170</b> includes a congestion management apparatus <b>104</b> (e.g., a congestion management module), clients <b>106</b><i>a, </i>a network <b>110</b>, and the database <b>108</b>. In one embodiment, the congestion management apparatus <b>104</b> may include and/or be controlled by at least one of the processor device and memory device. The congestion management apparatus <b>104</b> may reside on the wireless networking device <b>174</b> in order to provide error correction and improve the wireless communications. A portion of the congestion management apparatus <b>104</b> may be split across nodes and a portion may reside on the wireless networking device <b>174</b> and a portion may reside on the client <b>106</b><i>a. </i>The wireless networking device <b>174</b> and the server <b>172</b> may be connected to each other through the network <b>110</b>.

0020<figref idref="DRAWINGS">FIG. 2</figref> is a schematic block diagram illustrating one embodiment of an apparatus <b>200</b> for reducing network congestion through the use of random linear network coding. The apparatus <b>200</b> may include or may be the congestion management apparatus <b>104</b>. The apparatus <b>200</b> may include a data traffic measurement module <b>202</b>, a control module <b>204</b>, a network coding module <b>206</b>, and a validation module <b>208</b>, which are described below. In one embodiment, the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, and the validation module <b>208</b> may each include at least one processor device and/or memory. Alternatively, the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, and the validation module <b>208</b> may each share one or more processor devices and/or be controlled by one or more processor devices of the congestion management apparatus <b>104</b>, the server <b>102</b>, and/or the client <b>106</b>. It will be apparent to those skilled in the art that other processing and memory implementations, including various non-transitory computer readable storage media, may be used for storing and executing program instructions pertaining to the technique introduced herein, such as such as magnetic disk or tape, optical disk (e.g., CD-ROM or DVD), flash memory, solid-state disk (SSD), electronic random access memory (RAM), micro-electro mechanical and/or any other similar media adapted to store information.

0021In one embodiment, the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, and the validation module <b>208</b> may each be in communication with each other, and communication may occur over one or more types of communication frameworks or communication networks. The congestion management apparatus <b>104</b> may include, for example, mechanical, electrical and signaling circuitry needed to connect the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, and the validation module <b>208</b> to each other for communication and for sending and/or receiving data. In one embodiment, the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, and the validation module <b>208</b> may each include a processor device and memory, and/or be controlled by a processor device and memory (see <figref idref="DRAWINGS">FIG. 6</figref>).

0022The data traffic measurement module <b>202</b> analyzes and/or determines a data loss rate pertaining to a datastream between the server and the client. A datastream includes data packets sent and received between the server and the client. In one embodiment, the data traffic measurement module <b>202</b> can simultaneously determine the data loss rate pertaining to multiple datastreams between the server and multiple clients. The data loss rate pertaining to a datastream may be defined in different ways. In one embodiment, the data loss rate is the total number of data packets sent by either (i) the server <b>102</b>, (ii) the client <b>106</b>, or (iii) both the server <b>102</b> and the client <b>106</b>, but not received by the server <b>102</b> and/or the client <b>106</b> over a set period of time. For example, the data loss rate may be, during a one second interval, the total number of data packets sent by the client <b>106</b> to the server <b>102</b> that were not received by the server <b>102</b>. In another embodiment, the data loss rate is the total number of data packets resent by (i) the server <b>102</b>, (ii) the client <b>106</b>, or (iii) both the server <b>102</b> and the client <b>106</b> over a set period of time. An example of the data loss rate using this definition may be, during a one second interval, the total number of data packets resent by server <b>102</b> to the client <b>106</b>.

0023A data loss rate above a certain threshold has an adverse impact on the performance of real-time software applications running on the server <b>102</b> and/or the client <b>106</b>, including but not limited to video teleconferencing, video streaming, and graphic and network heavy online multiplayer games. Thus, measuring the data loss rate between the server <b>102</b> and the client <b>106</b> can help identify when network congestion is severely impairing the functionality of these applications. To more accurately measure the average data loss rate between the server <b>102</b> and the client <b>106</b>, it will be advantageous to vary the window of time during which the data traffic measurement module <b>202</b> counts the total number of data packets lost, was asked to retransmit packets, or packets were resent. Thus, for example, the data traffic measurement module <b>202</b> may count the total number of data packets lost between the server <b>102</b> and the client <b>106</b> over a five second interval. A longer sampling window gives the congestion management apparatus <b>104</b> a better understanding of the state of congestion within the network between the server <b>102</b> and the client <b>106</b> by better averaging the impact of momentary spikes or dips in network congestion. A shorter sampling window allows the congestion management apparatus <b>104</b> to more quickly react to changes in network congestion.

0024The data traffic measurement module <b>202</b> may determine the data loss rate pertaining to a datastream between the server <b>102</b> and the client <b>106</b> either continuously, at regular intervals (e.g., every 30 seconds), and/or at scheduled times (e.g., during peak network usage hours). Determining the data loss rate pertaining to a datastream continuously allows the data traffic measurement module <b>202</b> to maintain a moving window average of the data loss rate. For example, the data loss rate determined by the data traffic measurement module <b>202</b> may be the average of the most recent three data loss rates measured. In another example, the data loss rate determined by the data traffic measurement module <b>202</b> may be the weighted average of the most recent five data loss rates measured, with the more recently measured data loss rates weighted more heavily.

0025The control module <b>204</b> causes the server <b>102</b> and the client <b>106</b> to send and receive data packets from each other and the packets are encoded using random linear network coding. In one embodiment, the control module <b>204</b> causes the server <b>102</b> and the client <b>106</b> to send and receive data packets from each other, and the data packets can be encoded using random linear network coding in response to the data traffic measurement module <b>302</b> determining that the data loss rate is higher than or equal to a first threshold. The control module <b>204</b> also causes the server <b>102</b> and the client <b>106</b> to stop sending and receiving data packets encoded using random linear network coding between each other. In an embodiment, the control module <b>204</b> causes the server <b>102</b> and the client <b>106</b> to stop sending and receiving data packets encoded using random linear network coding between each other in response to the data traffic measurement module <b>202</b> determining that the data loss rate is lower than a second threshold (e.g., at least one additional threshold). In one embodiment, depending on configuration, additional thresholds may also be utilized and/or the data traffic measurement module <b>202</b> may determine that the data loss rate is lower than a at least one of the additional thresholds. Furthermore, in a particular case, the first threshold and second threshold may be the same threshold point but the first and second thresholds will more often be two separate thresholds.

0026In one embodiment, the first threshold and the second threshold are identical. But in another embodiment, the first threshold and the second threshold are different, with the first threshold greater than the second threshold. As explained further below, encoding data packets using random linear network coding increases overhead in terms of both packet header size and time spent encoding and decoding packet payloads. Thus, in certain scenarios, encoding data packets using random linear network coding will actually increase network congestion and result in lower data throughput rates. The first threshold and the second threshold should preferably be set to data loss rates that balance their effect on the performance of real-time software applications with maintaining the highest data throughput rates. That is, the first threshold and the second threshold may be dynamically and/or automatically adjusted and/or set to data loss rates for real-time load balancing of the various modules or applications of the server <b>102</b> and/or client <b>106</b> while maintaining the highest data throughput rates between the server <b>102</b> and the client <b>106</b>.

0027For example, assuming that a data loss rate above <b>20</b> packets per second will result in choppy video streaming between the server <b>102</b> and the client <b>106</b>, the first threshold may be set to <b>18</b> or <b>19</b> packets per second so that a higher data loss rate will cause the server <b>102</b> and the client <b>106</b> to encode data packets using random linear network encoding. In this example, the second threshold may be identical to the first threshold, or it may be set at a lower threshold to maintain a higher data throughput between the server <b>102</b> and the client <b>106</b>.

0028The network coding module <b>206</b> encodes data packets using random linear network coding and decodes data packets encoded using random linear network coding. Traditional TCP/IP transmission divides data content into sequentially numbered packets and sends each packet with its accompanying sequence number. If a packet (i) does not arrive at its destination and therefore an acknowledgement is not sent to the origin or (ii) an acknowledgement is sent but does not arrive at the origin within a specific window of time, the packet is resent. In random linear network coding, data are divided into data blocks and encoded into coded data packets. Each coded data packet is formed by multiplying each data block with a constant chosen randomly from a finite range of constants and then combining the results. Thus, each coded data packet can be represented by a linear equation in the following form:

0000<br />CDP1=C_1,1×DB_1,1+C_1,2×DB_1,2+... +C_1,m×DB_1,m

0000<br />CDP2=C_2,1×DB_2,1+C_2,2×DB_2,2+... +C_2,m×DB_2,m

0000<br />CDP k=C_k,1×DB_k,1+C_k,2×DB_k,2+... +C_k,m×DB_k,m

0029Here, CDP represents a “coded data packet,” DB represents a “data block,” and C represents a randomly chosen constant from a finite range of constants.

0030The randomly chosen constant C_k,mmultiplied with each data block are encoded in the headers of the coded data packets in which they are used. Assuming there are n data blocks to be sent, coded data packets are sent continuously until n distinct (i.e., linearly independent) coded data packets are received and acknowledged. Once n distinct coded data packets are received, they can be decoded to find the n data blocks. Alternatively, some individual coded data packets can be decoded as they are received. For example, given m distinct coded data packets encoded using a total of p unique data blocks, where m≧p, it is possible to decode the m coded data packets to find the p data blocks.

0031The number of data blocks used to encode a coded data packet can vary. In certain situations, it is advantageous to encode a coded data packet with a larger set of data blocks (i.e., a larger number of data blocks). For example, when the data loss rate in the network <b>110</b> reaches a certain threshold, encoding a coded data packet with a larger set of data blocks is desirable because each distinct coded data packet received will contain more data blocks that can be decoded. Thus, in one embodiment, the network coding module <b>206</b> increases the number of data blocks used to encode a coded data packet in response to the data traffic measurement module <b>202</b> determining that the data loss rate is higher than the first threshold. In other situations, it is advantageous to encode a coded data packet with a smaller set of data blocks (i.e., a smaller number of data blocks). An increase in the number of encoded data blocks leads to an increase in packet header size (due to a corresponding increase in the number of constants C_k,mencoded in the packet header) and packet payload size, as well as increases in time required to encode and decode the coded data packets. Thus, when the data loss rate in the network <b>110</b> is very low, encoding a coded data packet with a smaller set of data blocks is desirable because it reduces the overhead associated with encoding a larger number of data blocks. Thus, in one embodiment, the network coding module <b>206</b> decreases the number of data blocks used to encode a coded data packet in response to the data traffic measurement module <b>202</b> determining that the data loss rate is between the first threshold and the second threshold.

0032As explained above, random linear network coding adds overhead in terms of time required to encode and decode the coded data packets, as well as an increase in the size of the coded data packet header to include the randomly chosen constants. But the overhead incurred is typically small compared to the efficiency gained by the transmitter (e.g., the server <b>102</b> or the client <b>106</b>) not having to retransmit lost coded data packets and the receiver (e.g., the server <b>102</b> or the client <b>106</b>) only having to acknowledge the receipt of every distinct coded data packet. Since it is possible that not all coded data packets created by random linear network coding are distinct, the transmitter may have to send more than n coded data packets in order for n distinct coded data packets to be received. Thus, if network congestion is low and there is very little to no packet loss, sending coded data packets encoded using random linear network coding may use more network bandwidth compared to encoding and sending data packets using the traditional TCP/IP transmission protocol.

0033The validation module <b>208</b> authenticates the client <b>106</b> and determines whether the client <b>106</b> possesses valid authorization to encode and decode data packets using random linear network encoding. In one embodiment, the control module <b>204</b> causes the server <b>102</b> and the client <b>106</b> to send to and receive from each other data packets encoded using random linear network coding in response to the validation module <b>208</b> authenticating the client <b>106</b> and determining that the client <b>106</b> possesses valid authorization. The database <b>108</b> stores a unique identifier for each client <b>106</b>. This identifier can be a unique alphanumeric code, picture, or other authentication token. For example, the stored identifier may be an encrypted hash of a client's <b>106</b> MAC address. The database <b>108</b> also stores an indicator of whether the client <b>106</b> is authorized to encode or decode data packets using random linear network coding. In another embodiment, the control module <b>204</b> causes the server <b>102</b> and the client <b>106</b> to stop sending and receiving data packets encoded using random linear network coding between each other in response to the validation module <b>208</b> determining that the client <b>106</b> lacks valid authorization.

0034<figref idref="DRAWINGS">FIG. 3</figref> is a schematic block diagram illustrating another embodiment of an apparatus for reducing network congestion through the use of random linear network coding. The apparatus <b>300</b> includes a data traffic measurement module <b>202</b>, a control module <b>204</b>, a network coding module <b>206</b>, a validation module <b>208</b>, and a data traffic analysis module <b>302</b>. The data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, the validation module <b>208</b>, and the data traffic analysis module <b>302</b> have been described above. The data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, the validation module <b>208</b>, and the data traffic analysis module <b>302</b> may each include at least one processor device and/or memory. Alternatively, the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, the validation module <b>208</b>, and the data traffic analysis module <b>302</b> may each share one or more processor devices and/or be controlled by one or more processor devices of the congestion management apparatus <b>104</b>, the server <b>102</b>, and/or the client <b>106</b>. It will be apparent to those skilled in the art that other processing and memory implementations, including various non-transitory computer readable storage media, may be used for storing and executing program instructions pertaining to the technique introduced herein, such as such as magnetic disk or tape, optical disk (e.g., CD-ROM or DVD), flash memory, solid-state disk (SSD), electronic random access memory (RAM), micro-electro mechanical and/or any other similar media adapted to store information.

0035In one embodiment, the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, the validation module <b>208</b>, and the data traffic analysis module <b>302</b> may each be in communication with each other, and communication may occur over one or more types of communication frameworks or communication networks. The congestion management apparatus <b>104</b> may include, for example, mechanical, electrical and signaling circuitry needed to connect the data traffic measurement module <b>202</b>, the control module <b>204</b>, the network coding module <b>206</b>, the validation module <b>208</b>, and the data traffic analysis module <b>302</b> to each other for communication and/or sending and/or receiving data.

0036The data traffic analysis module <b>302</b> records one or more characteristics of the datastream between the server <b>102</b> and the client <b>106</b>. A characteristic of the datastream between the server <b>102</b> and the client <b>106</b> is the data loss rate pertaining to the datastream at various times (e.g., 8 a.m. to 5 p.m., day, week, month, Mondays, weekends, New Year's Day). Another characteristic of the datastream between the server <b>102</b> and the client <b>106</b> is the rate of change in the data loss rate pertaining to the datastream at various times. Yet another characteristic of the datastream between the server <b>102</b> and the client <b>106</b> is the data throughput rate pertaining to the datastream at various times. Still another characteristic of the datastream between the server <b>102</b> and the client <b>106</b> is the rate of change in the data throughput rate pertaining to the datastream at various times.

0037The one or more characteristics of the datastream between the server <b>102</b> and the client <b>106</b> may be stored in the database <b>108</b> and/or on the server <b>102</b> and allows other modules to leverage the one or more recorded datastream characteristics to provide additional functionality for the congestion management apparatus <b>104</b>. In one embodiment, the data traffic measurement module <b>202</b> changes the manner and/or frequency with which it determines the data loss rate for the datastream based upon an analysis of the one or more characteristics of the datastream recorded by the data traffic analysis module <b>302</b>. For example, the data traffic measurement module <b>202</b> may analyze the one or more characteristics of the datastream between the server <b>102</b> and a particular client <b>102</b> recorded by the data traffic analysis module <b>302</b> and determine that the datastream's data loss rate during a certain time (e.g., midnight to 5 a.m.) is consistently low. As a result, the data traffic measurement module <b>202</b> may lengthen the sampling window for measuring the data loss rate and also lengthen the interval between the times when it determines the data loss rate during that time. In another example, the data traffic measurement module <b>202</b> may analyze the one or more characteristics of the datastream between the server <b>102</b> and another client <b>102</b> recorded by the data traffic analysis module <b>302</b> and determine that the datastream's data loss rate varies greatly during a specific time of day (e.g., noon to 3 p.m.). In response, the data traffic measurement module <b>202</b> may shorten the sampling window for measuring the data loss rate and also continuously monitor the data loss rate during that time.

0038In another embodiment, the control module <b>204</b> causes the server <b>102</b> and the client <b>106</b> to send to and receive from each other data packets encoded using random linear network coding in response to an analysis of the one or more characteristics of the datastream recorded by the data traffic analysis module <b>302</b>. In an additional embodiment, the control module <b>204</b> causes the server <b>102</b> and the client <b>106</b> to stop sending and receiving data packets encoded using random linear network coding between each other in response to an analysis of the one or more characteristics of the datastream recorded by the data traffic analysis module <b>302</b>. For example, the control module <b>204</b> may analyze the one or more characteristics of the datastream between the server <b>102</b> and the client <b>106</b> recorded by the data traffic analysis module <b>302</b> and determine that a datastream's data loss rate, as well as the rate of change of the data loss rate, is low during a certain time of day (e.g., 8 a.m. to 3 p.m.). In response, the control module <b>204</b> may cause the server <b>102</b> and the client <b>106</b> to stop sending and receiving data packets encoded using random linear network coding between each other during that time.

0039<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart diagram illustrating one embodiment of a method for reducing network congestion through the use of random linear network coding. The method <b>400</b> begins and determines <b>402</b> the data loss rate pertaining to a datastream between a server <b>102</b> and a client <b>106</b>. The method <b>400</b> determines <b>404</b> whether the data loss rate is greater than or equal to a threshold. If the data loss rate is greater than or equal to the threshold, the method <b>400</b> causes <b>406</b> the server <b>102</b> and the client <b>106</b> to send to and receive from each other data packets encoded using random linear network coding and the method <b>400</b> ends. If the data loss rate is not greater than or equal to the threshold, the method <b>400</b> causes <b>408</b> the server <b>102</b> and the client <b>106</b> to stop sending and receiving data packets encoded using random linear network coding between each other and the method <b>400</b> ends. Thus, the congestion management apparatus <b>104</b> is configured to selectively “turn on” and/or selectively “turn off” in real time the random linear network coding on datapackets by determining whether the data loss rate is greater than or equal to a threshold.

0040<figref idref="DRAWINGS">FIG. 5</figref> is a schematic flow chart diagram illustrating another embodiment of a method for reducing network congestion through the use of random linear network coding. The method <b>500</b> begins and determines <b>502</b> the data loss rate pertaining to a datastream between a server <b>102</b> and a client <b>106</b>. The method <b>500</b> determines <b>504</b> whether the data loss rate is greater than or equal to a first threshold. If the data loss rate is greater than or equal to the first threshold, the method <b>500</b> causes <b>506</b> the server <b>102</b> and the client <b>106</b> to send to and receive from each other data packets encoded using random linear network coding and the method <b>500</b> ends. If the data loss rate is not greater than or equal to the first threshold, the method <b>500</b> determines <b>508</b> whether the data loss rate is less than a second threshold. In one embodiment, the first threshold and the second threshold are different, with the first threshold higher than the second threshold. If the data loss rate is less than the second threshold, the method <b>500</b> causes <b>510</b> the server <b>102</b> and the client <b>106</b> to stop sending and receiving data packets encoded using random linear network coding between each other and the method <b>500</b> ends. If the data loss rate is not less than the second threshold, the method <b>500</b> ends. Thus, the congestion management apparatus <b>104</b> is configured to selectively “turn on” and/or selectively “turn off” in real time the random linear network coding on datapackets by based on the data loss rate being either greater than or equal to either a first threshold and/or less than a second threshold.

0041<figref idref="DRAWINGS">FIG. 6</figref> illustrates a computing device <b>610</b> on which modules of this technology may execute. A computing device <b>610</b> is illustrated on which a high level example of the technology may be executed. The computing device <b>610</b> may include one or more processors <b>612</b> that are in communication with memory devices <b>620</b>. The computing device may include a local communication interface <b>618</b> for the components in the computing device. For example, the local communication interface may be a local data bus and/or any related address or control busses as may be desired.

0042The memory device <b>620</b> may contain modules that are executable by the processor(s) <b>612</b> and data for the modules. Located in the memory device <b>620</b> are modules executable by the processor. For example, a personalization module <b>624</b>, the video module <b>626</b>, and the user action module <b>628</b>, and other modules may be located in the memory device <b>620</b>. The modules may execute the functions described earlier. A data store <b>622</b> may also be located in the memory device <b>620</b> for storing data related to the modules and other applications along with an operating system that is executable by the processor(s) <b>612</b>.

0043Other applications may also be stored in the memory device <b>620</b> and may be executable by the processor(s) <b>612</b>. Components or modules discussed in this description that may be implemented in the form of software using high programming level languages that are compiled, interpreted or executed using a hybrid of the methods.

0044The computing device may also have access to I/O (input/output) devices <b>614</b> that are usable by the computing devices. An example of an I/O device is a display screen <b>630</b> that is available to display output from the computing devices. Other known I/O device may be used with the computing device as desired. Networking devices <b>616</b> and similar communication devices may be included in the computing device. The networking devices <b>616</b> may be wired or wireless networking devices that connect to the internet, a LAN, WAN, or other computing network.

0045The components or modules that are shown as being stored in the memory device <b>620</b> may be executed by the processor <b>612</b>. The term “executable” may mean a program file that is in a form that may be executed by a processor <b>612</b>. For example, a program in a higher level language may be compiled into machine code in a format that may be loaded into a random access portion of the memory device <b>620</b> and executed by the processor <b>612</b>, or source code may be loaded by another executable program and interpreted to generate instructions in a random access portion of the memory to be executed by a processor. The executable program may be stored in any portion or component of the memory device <b>620</b>. For example, the memory device <b>620</b> may be random access memory (RAM), read only memory (ROM), flash memory, a solid state drive, memory card, a hard drive, optical disk, floppy disk, magnetic tape, or any other memory components.

0046The processor <b>612</b> may represent multiple processors and the memory <b>620</b> may represent multiple memory units that operate in parallel to the processing circuits. This may provide parallel processing channels for the processes and data in the system. The local interface <b>618</b> may be used as a network to facilitate communication between any of the multiple processors and multiple memories. The local interface <b>618</b> may use additional systems designed for coordinating communication such as load balancing, bulk data transfer, and similar systems.

0047While the flowcharts presented for this technology may imply a specific order of execution, the order of execution may differ from what is illustrated. For example, the order of two more blocks may be rearranged relative to the order shown. Further, two or more blocks shown in succession may be executed in parallel or with partial parallelization. In some configurations, one or more blocks shown in the flow chart may be omitted or skipped. Any number of counters, state variables, warning semaphores, or messages might be added to the logical flow for purposes of enhanced utility, accounting, performance, measurement, troubleshooting or for similar reasons.

0048Some of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

0049Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more blocks of computer instructions, which may be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which comprise the module and achieve the stated purpose for the module when joined logically together.

0050Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices. The modules may be passive or active, including agents operable to perform desired functions.

0051The technology described here can also be stored on a computer readable storage medium that includes volatile and non-volatile, removable and non-removable media implemented with any technology for the storage of information such as computer readable instructions, data structures, program modules, or other data. Computer readable storage media include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other computer storage medium which can be used to store the desired information and described technology.

0052The devices described herein may also contain communication connections or networking apparatus and networking connections that allow the devices to communicate with other devices. Communication connections are an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules and other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. A “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media. The term computer readable media as used herein includes communication media.

0053Reference was made to the examples illustrated in the drawings, and specific language was used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the technology is thereby intended. Alterations and further modifications of the features illustrated herein, and additional applications of the examples as illustrated herein, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the description.

0054Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples. In the preceding description, numerous specific details were provided, such as examples of various configurations to provide a thorough understanding of examples of the described technology. One skilled in the relevant art will recognize, however, that the technology can be practiced without one or more of the specific details, or with other methods, components, devices, etc. In other instances, well-known structures or operations are not shown or described in detail to avoid obscuring aspects of the technology.

0055Although the subject matter has been described in language specific to structural features and/or operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features and operations described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. Numerous modifications and alternative arrangements can be devised without departing from the spirit and scope of the described technology.