阅读说明：本技术 用于识别数据分组网络中的候选流的系统和方法 (System and method for identifying candidate flows in a data packet network ) 是由 米歇尔·米勒 约翰·M·伯内特 本·哈多恩 戴夫·吉本斯 肖恩·布莱恩 于 2019-01-25 设计创作，主要内容包括：一种计算机实现的方法和传输管理器系统用于通过以下方式来减少网络拥塞：检测网络中的一个或多个数据流；使用候选流检测阈值来确定一个或多个数据流中的数据流是否是候选流,候选流检测阈值基于一个或多个数据流的一个或多个特性；以及响应于确定数据流是候选流,管理数据流。一个或多个数据流的消耗速率、持续时间、传递的字节的数量、吞吐量、或者聚合特性可以用于确定候选流检测阈值。(A computer-implemented method and transmission manager system for reducing network congestion by: detecting one or more data flows in a network; determining whether a data stream of the one or more data streams is a candidate stream using a candidate stream detection threshold, the candidate stream detection threshold based on one or more characteristics of the one or more data streams; and managing the data flow in response to determining that the data flow is a candidate flow. The consumption rate, duration, number of bytes delivered, throughput, or aggregate characteristics of one or more data streams may be used to determine the candidate stream detection threshold.)

1. A computer-implemented method for reducing network congestion, comprising:

detecting one or more data flows in a network;

determining whether a data flow of the one or more data flows is a candidate flow using a candidate flow detection threshold, the candidate flow detection threshold based on one or more characteristics of the one or more data flows; and

managing the data flow in response to determining that the data flow is the candidate flow.

2. The method of claim 1, further comprising:

determining a consumption rate of data carried by the data flow, the consumption rate of data being used to determine the candidate flow detection threshold.

3. The method of claim 2, wherein the consumption rate is related to a coding rate.

4. The method of claim 2, further comprising:

determining a throughput of the data flow, the throughput being used to determine the candidate flow detection threshold as a function of a transmission time required to buffer an amount of data corresponding to the consumption rate multiplied by a predetermined duration,

wherein the duration of the data stream is compared to the candidate stream detection threshold to determine whether the data stream is the candidate stream.

5. The method of claim 2, wherein a predetermined buffer growth rate value is added to the consumption rate to determine the candidate flow detection threshold, the method further comprising:

determining the throughput of said data stream, an

Comparing the throughput of the data flow to the candidate flow detection threshold to determine whether the data flow is a candidate flow.

6. The method of claim 1, further comprising:

determining a percentage of the plurality of data streams determined to be candidate streams;

comparing the determined percentage to a predetermined target percentage;

in response to the determined percentage being less than the predetermined target percentage, adjusting the candidate flow detection threshold to increase the number of the plurality of data flows determined to be candidate flows; and

in response to the determined percentage being greater than the predetermined target percentage, adjusting the candidate flow detection threshold to reduce the number of the plurality of data flows determined to be candidate flows,

wherein the candidate flow detection threshold is adjusted to determine the candidate flow detection threshold.

7. The method of claim 1, further comprising:

determining a distribution of the one or more characteristics or a distribution of a combination of the one or more characteristics;

determining a value corresponding to a predetermined percentile of the determined distribution; and

determining the candidate flow detection threshold according to the determined value.

8. The method of claim 1, wherein the method is performed by a first network node, the method further comprising:

receiving information about the plurality of data flows from a second network node; and

determining the candidate flow detection threshold using the received information.

9. The method of claim 1, wherein the method is performed by a first network node, the method further comprising:

receiving a network metric from a second network node; and

determining the candidate flow detection threshold using the received network metric,

wherein the first network node is a network node that receives the plurality of data streams.

10. The method of claim 1, further comprising:

determining a current time of day; and

determining the candidate flow detection threshold according to a current time of day.

11. The method of claim 1, further comprising:

determining a duration of time that the data flow is actively transmitting packets; and

comparing the duration to the candidate flow detection threshold to determine whether the data flow is the candidate flow.

12. The method of claim 1, further comprising:

determining a number of bytes communicated by the data stream; and

comparing the number of bytes to the candidate stream detection threshold to determine whether the data stream is the candidate stream.

13. A transport manager system, comprising:

one or more processors, a network interface, a queue, and a storage device communicatively coupled to one another, the storage device storing computer-executable instructions that, when executed by the one or more processors, cause the transmission manager system to:

detecting one or more data flows in a network;

determining whether a data stream is a candidate stream using a candidate stream detection threshold, the candidate stream detection threshold based on one or more characteristics of the one or more data streams; and

managing the data flow in response to determining that the data flow is the candidate flow.

14. The transport manager system of claim 13, wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a consumption rate of data carried by the data flow, the consumption rate being used to determine the candidate flow detection threshold.

15. The transport manager system of claim 14, wherein the consumption rate is related to an encoding rate.

16. The transport manager system of claim 14, wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a throughput of the data flow, the throughput being used to determine the candidate flow detection threshold as a function of a transmission time required to buffer an amount of data corresponding to the consumption rate multiplied by a predetermined duration,

wherein the duration of the data stream is compared to the candidate stream detection threshold to determine whether the data stream is the candidate stream.

17. The transport manager system of claim 14, wherein a predetermined buffer growth rate value is added to the consumption rate to determine the candidate flow detection threshold, and wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a throughput of the data stream; and

comparing the throughput of the data flow to the candidate flow detection threshold to determine whether the data flow is a candidate flow.

18. The transport manager system of claim 13, wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a percentage of the plurality of data streams determined to be candidate streams;

comparing the determined percentage to a predetermined target percentage;

in response to the determined percentage being less than the predetermined target percentage, adjusting the candidate flow detection threshold to increase the number of the plurality of data flows determined to be candidate flows; and

in response to the determined percentage being greater than the predetermined target percentage, adjusting the candidate flow detection threshold to reduce the number of the plurality of data flows determined to be candidate flows.

19. The transport manager system of claim 13, wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a distribution of the one or more characteristics or a distribution of a combination of the one or more characteristics;

determining a value corresponding to a predetermined percentile of the determined distribution; and

determining the candidate flow detection threshold according to the determined value.

20. The transport manager system of claim 13, wherein the transport manager system is included in a first network node, and wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

receiving information about the plurality of data flows from a second network node; and

determining the candidate flow detection threshold using the received information.

21. The transport manager system of claim 13, wherein the transport manager system is included in a first network node, and wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

receiving a network metric from a second network node; and

determining the candidate flow detection threshold using the received network metric.

22. The transport manager system of claim 13, wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a current time of day; and

determining the candidate flow detection threshold according to a current time of day.

23. The transport manager system of claim 13, wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a duration of time that the data flow is actively transmitting packets; and

comparing the duration to the candidate flow detection threshold to determine whether the data flow is the candidate flow.

24. The transport manager system of claim 13, wherein the computer-executable instructions, when executed by the one or more processors, cause the transport manager system to:

determining a number of bytes communicated by the data stream; and

comparing the number of bytes to the candidate stream detection threshold to determine whether the data stream is the candidate stream.

Background

One of the increasing problems faced by today's data networks, which may include wireless, wired and/or fiber optic networks, is the burden placed on these data networks by a single data flow ("stream") that consumes a disproportionate amount of network resources over an extended period of time during transmission to or from end user devices, which may be referred to as "elephant flow". Streaming media content (audio, video, and/or other types of content data), large downloads, and the like typically produce such elephant streams.

Consumer access networks are typically designed for the transmission of short bursts of data and short periodic use of network resources by client devices. As a result, large flows can be a major challenge for network traffic engineers attempting to meet peak usage demands of many users using limited network resources. The presence of a large number of unmanaged elephant flows in the network may create network congestion that results in a slow network response for all users and their applications.

Accordingly, it is desirable to be able to identify candidate flows (e.g., elephant flows) that may be managed (e.g., by per-flow bandwidth allocation) to preserve network performance.

Disclosure of Invention

Systems and methods are described herein for determining candidate flows (e.g., elephant flows) that may be processed and/or managed to prevent performance degradation of a network. Candidate flows may be determined using candidate flow detection thresholds that may be dynamically adjusted.

According to various embodiments, the candidate flow detection threshold may vary based on the network environment and many other factors. Embodiments may adjust the candidate flow detection threshold by: identifying a stream that is a video stream, and identifying or inferring the video encoding rate being delivered to the device by directly observing the encoding rate or by observing the throughput of the stream. The embodiment may calculate the amount of buffer that has been transferred and/or the rate at which the buffer is growing and use one or more of these values to adjust one or more candidate flow detection thresholds for that flow up or down.

Another embodiment may identify a target percentage of expected candidate flows for an entire data transmission network or a subset of the network (e.g., a single eNodeB, destination, source, subscriber type, etc.), and dynamically adjust the candidate flow detection threshold(s) until the target percentage of candidate flows is met.

Another embodiment utilizes percentiles of data transfer sessions across the entire data transfer network or a subset of the data transfer network (i.e., nodes within the data network, or content destinations, or content sources, content types, etc.) to determine candidate flow detection thresholds. For example, within a network node, an embodiment may find the value of the 90 th percentile of all data transfer session sizes and determine a candidate flow detection threshold for that network node based on that value. Other embodiments may similarly operate using other data transfer session indicators, including but not limited to data transfer session throughput or duration of a data transfer session, as inputs to determine an appropriate candidate flow detection threshold.

Another embodiment may measure the frequency of candidate flow identifications based on the source or destination of the data transmission session. This information may be used to increase or decrease the candidate flow detection threshold for that source or destination.

In another embodiment, an embodiment may receive information from another network node and utilize the information to adjust the candidate flow detection threshold upward or downward based on current data transmission network conditions reported by the network node. For example, if network node resource usage increases or decreases, embodiments may increase or decrease the number of candidate flows it detects for that network node.

In an embodiment, the candidate flow detection threshold may be adjusted based on the time of day, such that the threshold may be adapted to situations where traffic increases during a particular time of day, and then decreases during different time periods. Embodiments may allow for identification of multiple time periods for which different respective candidate flow detection thresholds are defined.

Drawings

FIG. 1A illustrates an example network environment.

FIG. 1B illustrates another example network environment.

Fig. 2A is a block diagram of a transmission manager system according to an embodiment.

Fig. 2B is a block diagram of a transmission manager system according to another embodiment.

Fig. 2C is a block diagram of a transmission manager system according to another embodiment.

Fig. 2D is a block diagram of a transmission manager system according to another embodiment.

Fig. 3 is a block diagram of a user equipment according to an embodiment.

Fig. 4 illustrates decision logic in accordance with an embodiment in which a candidate stream detector identifies a stream that may be video, and adjusts a candidate stream detection threshold based on the amount that has been delivered to the device.

Fig. 5 illustrates decision logic in accordance with an embodiment, wherein the candidate stream detector identifies a data transfer session, which may be video, or a data transfer session that is informed by another network node that the data transfer session is video, and adjusts the candidate stream detection threshold based on the rate of growth of the video playback buffer.

Fig. 6 illustrates decision logic in accordance with an embodiment in which a flow detector adjusts a candidate flow detection threshold to achieve a target percentage of candidate flows in a set of flows.

Fig. 7 illustrates decision logic in accordance with an embodiment in which a stream detector adjusts candidate stream detection thresholds to achieve a target percentile value among a set of streams.

Fig. 8 illustrates decision logic in accordance with an embodiment in which a candidate flow detector uses information collected by the candidate flow detector or reported from a separate network node and uses that information to adjust the candidate flow detection threshold for those flows.

Fig. 9 illustrates decision logic according to an embodiment, wherein the candidate flow detector adjusts the candidate flow threshold based on information received from another network node.

Fig. 10 illustrates decision logic in accordance with an embodiment in which a candidate flow detector adjusts a candidate flow detection threshold based on time of day.

FIG. 11 illustrates a computer system, according to an embodiment.

Detailed Description

Systems and methods are described herein for determining candidate flows (e.g., elephant flows) that may be processed and/or managed to prevent performance degradation of a network. Candidate flows may be determined using a candidate flow detection threshold.

When a data network is congested, the rate at which data packets (e.g., data flows or streams) traverse the network will typically decrease, resulting in less than optimal data throughput. One of the reasons for network congestion is the presence or existence of "elephant flows" or other types of flows that are relatively heavy when using network resources including shared throughput capacity.

Candidate flow detection may be performed at any point within the packet data network to identify heavy flows that may be managed to improve network performance. Candidate flow detection may be performed directly on the data traffic or on a duplicate of the traffic. There are many reasons for wanting to identify candidate flows in a network versus other data flows, including, but not limited to, applying quality of service (QoS) policies to candidate flows, creating security policies based on identified candidate flow behaviors, statistical analysis of user behaviors, and the like.

A flow may be defined as a flow of datagram packets from one or more source devices to one or more destination devices, regardless of the transport protocol. As an example, a flow may include one or more data transfer sessions. For example, if an end user device, such as a smartphone, initiates a video, it may create one data transfer session for the video stream and another data transfer session for the audio stream, both to the same destination server. According to various embodiments, this may be viewed as a single stream from the perspective of the candidate stream detection system.

Examples of candidate streams include, for example, packet data streams associated with media content (e.g., video and/or audio files) that use a large portion of the network bandwidth. In some cases, a candidate flow may be defined as a data flow that consumes a portion of the total network bandwidth that is greater than some threshold level. In other cases, a candidate flow may be defined as a data flow having a data rate that exceeds some threshold amount. In other cases, a candidate stream may be defined as a data stream having a duration greater than a threshold duration. Of course, the threshold level and the threshold amount values may be a design choice based on a number of factors including, for example, the type of data network involved, the number of end users, the total network bandwidth, and the like. In an embodiment, the threshold level may be dynamically adjusted.

The identification of candidate flows in the network may be accomplished based on one or more criteria. In one embodiment, flows exceeding a size threshold (e.g., transmitting at least 3MB) are classified as candidate flows. In an embodiment, a flow that transmits packets within a minimum amount of time is classified as a candidate flow (e.g., a flow that actively transmits packets within 45 seconds or longer). In another example, a candidate stream may be defined as a stream having a data rate that exceeds a certain threshold (e.g., 2 megabits/second). U.S. patent application No.15/060,486, filed 3.3.2016 and published as U.S. patent application publication No.2016/0261510, specifies example conditions and thresholds for identifying candidate streams (e.g., elephant streams), and is incorporated herein by reference in its entirety.

FIG. 1A illustrates an example network environment 100 according to an embodiment. As shown, the network environment 100 includes a transmission manager system 102a, a user device 104, a content server 106, a data network 108, and a data network 110. Although not explicitly shown in fig. 1A, one or more additional user devices 104 and one or more additional content servers 106 may interface with data network 108 and/or data network 110.

In embodiments, the user device 104 may be a desktop computer, a workstation, a set-top box, a workstation, a mobile computing device such as a smartphone or tablet computer, a wearable computing device such as a smart watch or augmented reality glasses, or the like.

In an embodiment, the content server 106 may be, for example, a server that provides media content (e.g., video and/or audio files and/or data files) to other network nodes including, for example, the user device 104.

The two data networks 108 and 110 may serve as paths for exchanging data in the form of data packets between the user equipment 104, the transport manager system 102a and the content server 106. For example, while a media content file (e.g., a video or audio file) is being downloaded from the content server 106 to the user device 104, the media content file may be routed from the content server 106 to the user device 104 through the transfer manager system 102a and via the data networks 108 and 110. For example, the content server 106 may send the media content file to the user device 104 via the data networks 108 and 110 by sending a data packet (the header) with a header that includes the network address (e.g., internet protocol, IP, address) of the user device 104 as a destination. In an embodiment, the two data networks 108 and 110 may be two different networks or may be part of a single, large function network.

In some embodiments, the data network 108 may be AN Access Network (AN) that communicatively links the transmission manager system 102a to the user equipment 104. For example, in some cases, the data network 108 may be one of a mobile cellular access network, such as a second generation (2G) network, a third generation (3G) network, a Long Term Evolution (LTE) network, a fifth generation (5G) network, and so forth. In some cases, the data network 108 may include a core set of child nodes linked to a Radio Access Network (RAN). In some cases, portions of the data networks 108, 110, 114 may be local area networks or data centers, such as serving gateway interface-local area networks (SGi-LANs) or gateway interface-local area networks (Gi-LANs) located at the boundaries of a mobile network.

In some embodiments, the data network 110 linking the content server 106 to the transmission manager system 102a may be a Wide Area Network (WAN), which may be considered the internet for purposes of illustration.

In some embodiments, it may be assumed that at least a selected portion of the packet data traffic between the content server 106 and the user equipment 104 passes through the transport manager system 102a or is consistent with the transport manager system 102 a. To facilitate traffic passing through the transport manager system 102a, in one embodiment, the physical location of the transport manager system 102a may be located at the boundary traffic aggregation point(s) connecting the data network 108 (e.g., an access network such as a cellular or Wi-Fi network) with the data network 110 (e.g., a WAN). However, in other embodiments, the transport manager system 102a may be located elsewhere. In some embodiments, the transport manager system 102a may be part of a Content Delivery Network (CDN) serving one or more ANs.

As will be described with reference to fig. 2A and 2B, the transmission manager system 102A includes a stream detector to monitor multiple data streams and select one or more data streams for further processing and/or management.

FIG. 1B illustrates another example network environment 150 according to an embodiment. As shown, the network environment 150 includes a transport manager system 102b designed to manage data flow between two network devices (e.g., the user device 104 and the content server 106), similar to the transport manager system 102a of fig. 1A. The transport manager system 102B of FIG. 1B includes components similar to those included in the transport manager system 102a of FIG. 1A. However, unlike the transport manager system 102a shown in fig. 1A, the transport manager system 102B of fig. 1B does not include a flow detector. Instead, the flow detector is part of the flow detector system 112.

The flow detector system 112 includes a network interface 160, one or more processors 162 (e.g., Central Processing Units (CPUs), Graphics Processing Units (GPUs), etc.), storage 164 (e.g., volatile and/or non-volatile memory), and a flow detector 166. The flow detector 112 may be designed to, among other characteristics, monitor and/or sample data traffic between the content server 106 and the user device 104 via the data networks 108, 110, and 114, as described below with reference to fig. 2A-2D. The flow detector system 112 and the transport manager system 102B of fig. 1B may be linked by a data network 114, which in some embodiments, the data network 114 may be a local area network or a software defined network, such as one or more networks comprised of directly interconnected sets of hardware of routers, switches, gateways, etc. In some embodiments, the three data networks 108, 110, and 114 may be a single functional network.

In an embodiment, selective packet data flows may be identified based on configuration policies or templates characterizing data flows traversing the data networks 108, 110, and 114 for further processing by the flow detector system 112 to identify candidate flows. For example, the flow detector system 112 may employ the flow detector 166 to measure the average throughput, amount of data transferred, duration, and other characteristics of the data flow, to classify the flow as a candidate flow (a candidate flow is a relatively heavy type of data flow because it is relatively large and disproportionately uses network resources including shared throughput capacity), and to determine that the elephant flow is a candidate flow for management.

The particular flow type (e.g., elephant flow) of packets flowing through data networks 108, 110, and 114 may be determined based on, for example, the component packet network and transport layer headers of the packets, which may include, for example, a combination of IP source and destination addresses, Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) source and destination ports, protocols (e.g., IPv4), flow labels (e.g., IPv6), flags, extended header fields, and so forth. That is, different packets may be identified as belonging to the same data flow (or virtual flow), e.g., by processing the packet's header to determine that the packets have, e.g., the same source and destination ports, protocols, flow labels, extended header fields, etc. Once a data flow (i.e., packet data flow) is identified, characteristics of the identified data flow (e.g., amount of data being carried, duration, etc.) may be determined to determine whether the data flow is a candidate flow.

In some embodiments, data flows are identified as candidate flows by sampling packets of an aggregate combination of one or more flows and selecting flows that exceed a threshold data rate measured over a defined sampling duration. In other embodiments, data streams are identified as candidate streams by sampling and selecting streams that exceed a continuous activity duration threshold, where the continuous activity duration threshold may be defined by measuring multiple continuous data rates or a series of data rates, where each data rate exceeds a threshold data rate. In other embodiments, data flows are identified as candidate flows by randomly sampling only some packets of an aggregate combination of one or more flows and selecting flows that exceed a relative detection probability that indicates a relatively disproportionate use of aggregate traffic bandwidth. In other embodiments, these methods may be used in combination or with other similar methods.

In some cases, when the network or transport layer packet data payload is encrypted or obscured, the payload header may be processed/examined to identify packets belonging to the same packet data flow. In other cases, where the packet data payload is readable, information in the network or transport packet payload may be processed/examined to further assist in identifying packets associated with a particular data stream or data stream type (e.g., streaming video).

In some embodiments, once flow detector system 112 identifies a candidate flow or another flow that may be heavy, flow detector system 112 may trigger reconfiguration of packet forwarding logic in data network 114 such that packets in the identified data flow are directed through transport manager system 102b in an end-to-end path between a source (e.g., content server 106) and a destination (e.g., 104). For example, the flow detector system 112 may communicate characteristics of the candidate flows to one or more routers and switches comprising the data network 114. Thus, dynamically configured forwarding or switching rules may be used to direct subsequent packets in a candidate flow through the transport manager system 102b in the end-to-end path of the packet, e.g., using principles of software defined networking. However, in other embodiments, according to default rules, the transport manager system 102b may be included in the end-to-end path, and the flow detector system 112 may only notify the transport manager system 102b of detected flows that match one or more classification templates, such that the detected flows are processed (e.g., by adjusting flow rates to reduce delivery rates of the detected flows), while other traffic flows may be forwarded without being processed.

In some cases, flows may be unidirectional (e.g., uplink or downlink flows) or may be bidirectional by pairing with flows in the opposite direction (e.g., packets with interchanged destination and source network addresses, interchanged port addresses, common flow labels, etc.) that belong to a communication pair connecting endpoints. In some embodiments, both directions of a bi-directional flow pair may be directed to the transport manager system 102 b.

In some embodiments, the flow detector system 112 and the transport manager system 102B may be different functional elements as shown in FIG. 1B, or combined into a single functional unit as shown in FIG. 1A.

Fig. 2A illustrates a transport manager system 200a that may be used to implement the transport manager system 102A of fig. 1A. The transmission manager system 200a includes a network interface 202 (e.g., a network interface card or "NIC"), one or more processors 204, a queue 206 (e.g., a buffer), a flow detector 166, and a storage device 208 (i.e., a non-transitory computer-readable medium, such as volatile and/or non-volatile memory, including, for example, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, disk storage, etc.) linked together via a bus 210. Storage 208 may store one or more applications 214 (e.g., computer readable instructions) and one or more policies 216 for selecting and/or determining which packet data flows should be managed.

Flow detector 166 may be designed to detect and monitor multiple data streams and act as a candidate flow detector by selecting one or more data streams as candidate flows for further processing/management, among other characteristics. The selection of candidate streams may be based on one or more policies 216 stored in storage 208 or from other sources. In various embodiments, the flow detector may be implemented using custom circuitry (e.g., an application specific integrated circuit or ASIC), or by employing a combination of custom circuitry and software executed by programmable circuitry (e.g., one or more processors).

As further shown in fig. 2A, the transport manager system 200a also includes a stream manager 212A, which may be designed to measure, among other characteristics, a transport performance (e.g., a transport throughput or some other transport parameter) of a data stream (i.e., a packet data stream). The stream manager 212a may detect whether the network is congested based at least in part on the measured delivery performance of the data stream, and may pace (pace) the data stream by adjusting delivery of the data stream to a destination (e.g., the user device 104) to reduce a delivery rate of the data stream in response to detecting the network congestion. In the embodiment illustrated in fig. 2A, the stream manager 212A is implemented by one or more processors 204 (or other programmable circuitry) executing one or more computer-readable programming instructions (e.g., applications 214). The stream manager 212a, 212B of fig. 2B, and the stream detector 166 of fig. 2B are logical units each designed to perform various functions to be described herein.

FIG. 2B illustrates another transport manager system 200B that may be used to implement the transport manager system 102a of FIG. 1A. The transport manager system 200b includes some of the same components as the transport manager system 200a of fig. 2A. However, unlike the stream manager 212A of fig. 2A, the stream manager 212B shown in fig. 2B may be implemented using custom circuitry, rather than using one or more processors 204 executing software (e.g., machine-readable programming instructions).

In other embodiments, the stream manager 212A of fig. 2A or the stream manager 212B of fig. 2B may be implemented using a combination of custom circuitry and software executed by programmable circuitry (e.g., by the processor 204).

Fig. 2C illustrates a transport manager system 200C that may be used to implement the transport manager system 102B of fig. 1B. The transport manager system 200c includes many of the same components as the transport manager system 200a of fig. 2A, but does not include the flow detector 166 of the transport manager system 200 a.

FIG. 2D illustrates another transport manager system 200D that may be used to implement the transport manager system 102B of FIG. 1B. The transport manager system 200d includes many of the same components as the transport manager system 200B of fig. 2B, but does not include the flow detector 166 of the transport manager system 200B.

In an embodiment, a stream manager, such as stream manager 212a or stream manager 212b, may be used in conjunction with stream detector 166 to act as a candidate stream detector to identify candidate streams that should be managed.

Fig. 3 is a block diagram of a user device 104 according to an embodiment. User device 104, which in some cases may be a mobile computing device or a desktop computer, may include a network interface 302 (e.g., a NIC), one or more processors 304, a user interface 306 (e.g., including a display, speakers, keyboard, mouse, etc.), and storage 308 (e.g., volatile and/or non-volatile memory) coupled together via a bus 310. Storage 308 may store one or more applications 314 and one or more files 316 (e.g., media content files such as audio and/or video files). In some embodiments, the one or more processors 304 may execute one or more computer-readable instructions (e.g., applications 314) to implement a proxy 312, which proxy 312 may be designed to facilitate various functions performed by the transport manager system 102a of fig. 1A and/or the transport manager system 102B of fig. 1B.