Network path redirect
By receiving the path quality indicator and redirecting the network service according to its indication, network devices can solve the problem of lack of client experience insights when targeting the network service, achieving better client experience quality.
Patent Information
- Application Number
- CN202080075383.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-10-28
- Filing Date
- 2020-10-19
- Publication Date
- 2025-05-27
- Estimated Expiration
- 2040-10-19
AI Technical Summary
Existing network devices lack real-time insight into the client experience when directing network services, resulting in the possibility of being unable to choose a network path that provides a better client experience.
By receiving the path quality indicator, the network device can evaluate whether the network service directed by the first network path meets the experience criteria, and if not, the network service redirects the network service through the second network path.
It realizes dynamic adjustment of network paths based on real-time client experience to improve the quality and stability of client experience.
Smart Images

Figure CN114616810B_ABST
Abstract
Description
Background Art
[0001] Data exchanged between two devices over a network can be relayed by any number of intermediate network devices. Depending on the particular network architecture, there may be multiple potential network paths available for network traffic. In other words, between two network endpoints, there can be one or more network devices that have access to multiple paths through which they can direct network traffic. Summary of the Invention
[0002] This Summary of the Invention is provided to introduce a selection of design concepts that are further described below in the Detailed Description in a simplified form. This Summary of the Invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additionally, the claimed subject matter is not limited to implementations that solve any or all of the disadvantages noted in any part of this disclosure.
[0003] A method for directing network traffic includes: at a network device, receiving network traffic provided by one or more client computing devices. The network device directs the network traffic to a service entity via a first network path. Receiving a path quality indicator that indicates whether the network traffic directed via the first network path meets one or more experience criteria. At least based on the path quality indicator indicating that the network traffic directed via the first network path does not meet the one or more experience criteria, the network device redirects some or all of the network traffic to the service entity via a second network path. Brief Description of the Drawings
[0004] Figure 1 Schematically depicts the exchange of network traffic between a service entity and multiple client computing devices.
[0005] Figure 2 Illustrates an example method for directing network traffic.
[0006] Figures 3A - 3C Schematically shows the redirect of network traffic from a first network path to a second network path.
[0007] Figure 4 Schematically shows an exemplary set of historical experience quality data.
[0008] Figure 5A and Figure 5B Schematically shows the redirect of network traffic from the second network path back to the first network path.
[0009] Figure 6 Schematically shows the transmission of network traffic on a third network path.
[0010] Figure 7 An example computing system is shown schematically. DETAILED DESCRIPTION
[0011] As discussed above, data sent over a network can be directed over any number of different network paths. Such data can be encapsulated as network packets (e.g., UDP, TCP / IP packets). The amount of such data at any given time and / or the total amount of such data over a particular time period can be referred to as network traffic.
[0012] When data is sent over different network paths, network traffic can be routed between different sets of intermediate network devices. For example, a network device (e.g., a router) can receive network traffic from one or more client devices and direct such traffic to a service entity, e.g., a service entity that provides a website, an office productivity suite, or other network-accessible services. Such traffic can be transmitted or relayed by a variety of different intermediate network devices, e.g., including network routers, repeaters, and switches controlled by one or more parties.
[0013] Depending on the particular circumstances in which network traffic is being sent, some potential network paths between two devices (e.g., a service entity and a network device) can provide a better client experience than other network paths. For example, depending on the type / quantity of data being sent, the hardware capabilities of the intermediate network devices, the current network load, etc., some network paths may provide a slow, intermittent, or unstable connection, which can have a negative impact on the client experience. Although some network devices are configured to dynamically redirect network traffic to use a different path based on detecting poor or unstable network performance, such devices typically lack insight into the actual application experience of the client device. As a result, it may be the case that the client experience is improved by sending some or all of the network traffic over different network paths, but the network device does not redirect the traffic due to insufficient information about the client experience. As will be described in more detail below, an application (e.g., implemented by a service entity) can evaluate how network conditions affect the client experience provided by the application and output a signal via decision logic that indicates whether network traffic should be redirected to use a different network path and how much traffic should be redirected.
[0014] In an example scenario, multiple client computing devices on a local network can send network traffic to a network device (e.g., a branch router), and then the network device can direct the network traffic to a service entity over the Internet. Due to unstable network conditions along the network path between the network device and the service entity, the application experience of the client computing devices may be poor, e.g., due to latency or buffering. However, from the perspective of the network device that relays the network traffic to the service entity, the network performance may seem sufficient because the requested content is reaching its intended destination. In other words, relatively low-level network hardware has no insight into how the current network conditions are having a positive or negative impact on the current application experience. For example, if the network device switches some or all of the network traffic to a different network path, it may potentially improve the overall client experience, e.g., because the new network path can handle more bandwidth. In other words, the network device responsible for selecting the network path has limited information about the actual client experience, and this may cause the network device not to explore alternative network paths that may potentially improve the client experience.
[0015] Figure 1 A network environment is schematically depicted in which network traffic is exchanged between a service entity and multiple client computing devices. Specifically, multiple client computing devices, including devices 100A - 100C, each provide network traffic to a network device 102, and the network device 102 sends the network traffic to a service entity 112. The network device can select a network path over the Internet through which the network traffic is directed to the service entity 112. It is noted that in any case where the network device receives feedback and / or redirects network traffic, such actions can actually be performed by management plane software associated with the network device or a separate management server. A "service entity" refers to a collection of one or more devices that work together to provide a network-accessible application or service, and each of the one or more devices may be co-owned / operated by the same company or organization. Thus, the "service entity" as shown in Figure 1 and other figures described herein will refer to at least one hardware device and will typically include multiple hardware devices, including front-end servers and back-end servers. As a non-limiting example, the service entity 112 can include server computers configured to provide streaming video, streaming game content, cloud-hosted data, and / or video conferencing. The client computing devices 100A - C can actually be any type of computing device, including smart phones, tablets, personal computers, other server computers, virtual / augmented reality devices, or Internet of Things devices. In many cases, the client computing devices will be located behind a firewall or other mechanism that hides the internal network details of the client from the service entity. In Figure 1 the example of, the network device 102 provides a firewall 116.
[0016] The network device 102 can direct network traffic through a first network path 104 or a second network path 106. Paths 104 and 106 together represent a selected portion of the larger Internet. Notably, the network device 102 can take the form of a network router and, in some cases, can be owned or operated by the same party (such as a company or organization) that maintains the client computing devices, which is typically separate from the party that maintains the service entity. Each of these two network paths is provided by a plurality of intermediate network devices. Specifically, devices 108A and 108B are used for the first network path 104, while devices 110A and 110B are used for the second path 106. Depending on the current network conditions, the first network path 104 or the second network path 106 can enable faster, more efficient, more reliable, and / or cheaper data exchange between the service entity and the network device 102, which can provide a correspondingly better application experience for the client devices 100A - C. However, as discussed above, due to the lack of information about the actual application performance experienced by the client computing devices, the network device 102 may not always select the optimal network path to direct its network traffic through.
[0017] Accordingly, the present disclosure relates to techniques for redirecting network traffic. A network device (e.g., a network router such as device 102) can direct network traffic received from one or more client computing devices to a service entity through a first network path. When directing network traffic through the first network path, the network device receives a path quality indicator that reflects whether the current client experience provided by the first network path meets one or more experience criteria. The path quality indicator can be received, for example, from the service entity, accessed from a network repository, or obtained from another suitable source. For example, any or all of the service entities, client computing devices, and various network devices can contribute network telemetry 115 to the network repository 114, and such telemetry can include or be used to generate the path quality indicator. Thus, the network device 102 can receive the path quality indicator from the network repository in response to a request from the network device, and / or the path quality indicator (and / or other diagnostic data) can be pushed to the network device 102. Regardless of the source of the path quality indicator, if the experience criteria are not met, the network device can redirect some or all of the network traffic through a second network path, which can provide a better client experience than the first network path. In some cases, the path quality indicator can suggest that the network device take a specific action, e.g., "redirect X% of the traffic to an alternative path", to reduce the decision-making by the network device. Additionally or alternatively, the path quality indicator can include diagnostic or telemetry data that can be analyzed and acted upon by the network device.
[0018] It should be noted that depending on how much information is available about the second network path, the application and / or network device may not know how the client experience will be affected by redirecting network traffic. Even if there are some signals available about the current performance of the second network path, there is generally a risk that suddenly sending more traffic over the second network path will have a negative impact on the performance of the second network path and thus on the application experience of the client device. Thus, as used herein, "redirecting network traffic" does not necessarily involve redirecting all network traffic that is currently flowing over the first network path. Instead, in some examples, only a relatively small amount of network traffic may be redirected to use the second network path, and the client experience associated with the redirected traffic can be monitored to evaluate the performance of the second path. In some examples, the amount of traffic redirected can be managed by a policy setting on the network device. Similar policy settings can control when and whether traffic redirect should be stopped (e.g., because the first network path has improved), or whether all network traffic should be redirected. Additionally or alternatively, the rate at which traffic is redirected can be determined or influenced by a cloud application implemented by the service entity, e.g., based on a path quality indicator or action recommendation generated by the application and provided to the network device or a management plane device that manages the network device.
[0019] It should be understood that Figure 1 the network devices and architectures shown therein are illustrative and non-limiting. The physical devices associated with the service entity, network devices (e.g., devices 102, 108A / B, 110A / B), client computing devices, and any devices implementing the network repository can have any suitable hardware configuration and form factor. Any or all of the devices associated with the service entity, network devices, client computing devices, and network repository can in some cases be implemented as the computing system 700 described below for Figure 7 description.
[0020] Generally, the service entity will provide some type of network-accessible application or other service. The client computing device can be a user computing device (e.g., laptop computer, desktop computer, smartphone, tablet, augmented / mixed reality device) and / or a client router, while the service entity can include one or more network servers, or any other network-accessible device. This disclosure is primarily concerned with scenarios where the network device receives network traffic from multiple client devices and sends such traffic to the service entity, although there can be any number of client computing devices, including just one. When there are multiple client computing devices, the traffic sent to the network device by some client computing devices can be directed over a different network path than the traffic from other client computing devices.
[0021] A network device can be any suitable device that enables, facilitates, or otherwise participates in the exchange of network traffic between a service entity and a client computing device. For example, the network device can be a network router, switch, modem, repeater, or server. However, it should be understood that the network traffic redirection techniques described herein can be applied to any scenario in which two devices exchange data traffic over a network, and the present disclosure is not limited to an environment that includes a service entity and a client device.
[0022] For simplicity, only two different network paths are shown, each network path including two intermediate network devices. However, in a typical network, any number of potential network paths can exist, each path including any number of intermediate network devices. In addition, some network paths can have one or more intermediate network devices in common.
[0023] The client computing device, service entity, and network device can communicate in any suitable manner and over any suitable computer network, including a local area network and / or a wide area network (e.g., the Internet). Any or all of the devices can communicate via a wired connection and / or a wireless connection. The network traffic between the client device and the service entity can take any suitable form, including any type and amount of computer data, and can last for any length of time. The network traffic can be bidirectional or unidirectional. By way of example, the network traffic can include streaming digital media (e.g., audio and / or video), streaming game data, peer-to-peer data exchange, Internet Protocol voice / video (VoIP) calls, and / or any other type of network traffic. Such data can be sent using any suitable protocol (e.g., UDP, TCP / IP packets).
[0024] Figure 2 An example method 200 for redirecting network traffic is shown. For example, when network traffic is being passed between a service entity and one or more client computing devices, the learning obtained from the corresponding client experiences can be used to generate a path quality indicator that can be used as a signal to a network device to indicate whether some or all of the network traffic should be redirected to use a different path. Method 200 can be implemented by any device suitable for sending or relaying digital information over a computer network, including, for example Figure 1 the network device 102 shown in Figure 7 In some cases, method 200 can be implemented by the computing system 700 described below with respect to
[0025] At 202, method 200 includes: receiving network traffic provided by one or more client computing devices. This is shown in Figure 3Ais schematically shown, which shows an example network device 300 that receives network traffic 302 from a client computing device 304. Similar to the devices described above with respect to Figure 1 the devices described, all of the devices referenced in Figures 3A - 6 are schematic in nature and are provided as non-limiting examples. Any or all of the devices described with respect to Figures 3A - 6 can be implemented as the computing system 700 described below with respect to Figure 7 . Additionally, any number of intermediate devices can exist between the network device and the client device and between the network device and the service entity.
[0026] Furthermore, as discussed above, the network traffic received by the network device can include any type and amount of data and can be received over any length of time. In one example scenario, the network device can be a router, the client computing device can be a user computing device such as a desktop computer or a laptop computer, and the service entity includes a web server configured to implement a network service or application. For example, the network traffic can take the form of web traffic received by the network device 300 from multiple client computing devices, each client computing device attempting to send traffic to the same service entity, and / or the network traffic can include any other computer data. As used herein, "receiving" network traffic can include traffic that is "pushed" to the network device as well as traffic that is requested or "pulled" by the network device.
[0027] Briefly returning to Figure 2 , at 204, method 200 includes: directing network traffic to a service entity via a first network path. This is also schematically shown in Figure 3A where the network device 300 directs the network traffic 302 to the service entity 306 via a first network path 308A, as shown by the solid line. A second potential network path 308B is shown as a dashed line to indicate that the network traffic is not currently being directed via the second network path. As discussed above, a service entity (such as service entity 306) refers to a collection of one or more devices that work together to provide a network-accessible application or service, and each of the one or more devices can be co-owned / operated by the same company or organization. In Figure 3A , each of the two potential network paths leads to a different device associated with the service entity and can include, for example, a front-end server.
[0028] For simplicity, Figure 3A only one client computing device is shown in Figure 1Similarly, network traffic from any number of client computing devices can be directed by a network device to a service entity. Additionally, only two network paths are shown, although any number of potential network paths may be available between the network device and the service entity, and each of these network paths may be implemented by any number of intermediate network devices.
[0029] Returning again Figure 2 , at 206, method 200 includes: receiving a path quality indicator that indicates whether network traffic directed through a first network path meets one or more experience criteria. This is shown in Figure 3B where network device 300 receives path quality indicator 310. Notably, the path quality indicator can be "received" in any suitable manner, and "receiving" the path quality indicator can include: accessing information that has been published by another device (such as network repository 312). In other words, the network device or the management plane associated with the device can read the path quality indicator from the network repository and implement a policy change for the network device.
[0030] The path quality indicator can take any suitable form. In some cases, the path quality indicator can be a binary value (e.g., 0 or 1) indicating whether the current performance of the first network path meets one or more experience criteria. Alternatively, the path quality indicator can take a non - binary form, such as a 100 - point scale or a value between 0 and 1. The path indicator can be represented as a request or include a recommended action, such as recommending redirecting some or all network traffic to use a different path. For example, a network device can redirect network traffic based on a path redirect request received from a service entity, the path redirect request being generated based at least on the path quality indicator and one or more historical path quality indicators. The path redirect request can optionally specify the percentage of the total traffic destined for the service entity that should be redirected, e.g., 5%. In some cases, the path quality indicator can include diagnostic data provided by one or more devices that facilitate or participate in the network traffic exchange, and the network device can be configured to: analyze or interpret the diagnostic data to determine whether to redirect network traffic through a different network path. In some embodiments, the path quality indicator can follow a predefined pattern and / or can aggregate information from multiple sources and / or aggregate information across multiple times.
[0031] The path quality indicator can be received from any suitable source. In one example, the path quality indicator can be received from a service entity. Typically, the service entity will determine that network problems are negatively impacting the client experience based on traffic arriving along a particular network path and send a path quality indicator indicating that the traffic should be redirected.
[0032] In Figure 3BIn the example, the network device accesses the path quality indicator from the network repository 312, which can be configured to receive and maintain network telemetry data from any or all of the devices involved in a particular network communication. As discussed above, in any case where a so-called "device" performs some function, the function can actually be performed by the management plane associated with the device, which can be implemented on a separate management server in some cases. In one example scenario, the path quality indicator can be generated and sent to the network repository by a service entity, as Figure 3B shown in Figure 3B , the network device (or the management plane associated with the network device) can access the path quality indicator from the repository. At this time, the policy for managing the network device can be changed so that the network device directs some or all network traffic through different network paths. Alternatively, the service entity, the network device, and / or the client computing device can provide diagnostic data to the network repository, and the network repository can derive the path quality indicator from the provided diagnostic data. As another example, the network device can retrieve diagnostic data provided by other devices from the network repository, and the network device can derive the path quality indicator based on the diagnostic data.
[0033] As discussed above, the path quality indicator indicates whether the network traffic directed through the first network path meets one or more experience criteria. Any number of such criteria can be used. As an example, one or more experience criteria can include one or more of detected network latency, reduced throughput for file downloads, detected network jitter, and the number of detected packet losses. These metrics can be measured at any suitable source, e.g., the service entity, intermediate network devices, and / or client computing devices. The path quality indicator can reflect a history-based recurring condition that is resolved by proactive logic to divert traffic. In some cases, the experience criteria can be specific to a certain type of data included in the network traffic. For example, when the network traffic includes digital video, one or more experience criteria can include one or both of the resolution and frame rate of the digital video. When the service entity tracks the experience criteria, the performance metrics can include requests sent by multiple client computing devices. For example, when most client computing devices are requesting low-resolution video, the service entity can determine that the performance of the current network path is insufficient even if the service entity has the bandwidth to support high-resolution video. Generally, any criteria can be used to evaluate the current performance of the network path. Such criteria can be tracked by any suitable device, and any suitable threshold can be used to determine that the current client experience does not meet the experience criteria.
[0034] In addition, in some examples, one or more experience criteria may include a comparison between the current network path and other potential network paths. Thus, even if the current client experience is relatively poor, the current network path may meet one or more experience criteria, for example if the network device predicts (e.g., based on historical data) that switching to a different network path will provide even worse performance, or cause a more significant disruption to the current service. Additionally or alternatively, one or more experience criteria may include the predicted cost of cutting over from the current network path. For example, the network device may predict that switching from a first network path to a second network path will provide an overall better client experience, but may also cause a significant short-term disruption to the client experience. Thus, any or all of the management plane of the network device, the network device itself, and the path quality indicator may recommend when or whether network traffic should be redirected based on any or all of the known information about the first and second network paths. For example, in some examples, the network device may determine that the current network path meets one or more experience criteria and choose not to redirect network traffic at that time.
[0035] In some cases, once a path quality indicator is received, it may be stored as part of a collection of historical experience quality data. This is schematically illustrated in Figure 4 which shows an exemplary collection of historical experience quality data 400, including a plurality of path quality indicators 402A - 402C. These path quality indicators may be received at different times, from different sources, and / or correspond to different network paths. As will be described in more detail below, such historical data may be considered in some cases when determining when or whether to redirect network traffic over a different network path.
[0036] Before redirecting network traffic to a service entity over an alternative network path, the network device may, in some cases, evaluate the current state or quality of the alternative path. Returning to Figure 2 , at 208, method 200 optionally includes evaluating an alternative network path over which some or all of the network traffic may potentially be directed to the service entity. This may be done in any suitable manner, for example, via comprehensive monitoring of the alternative path, or by evaluating any real-time traffic currently flowing between the network device and the service entity over the alternative network path.
[0037] At 210, method 200 optionally includes: determining whether the alternative path is suitable for sending network traffic to the service entity. If not, method 200 returns to 208, where a different alternative network path is evaluated. This may be repeated as needed until a suitable alternative network path is identified, all potential network paths are exhausted, or the conditions along the first network path improve such that traffic redirect is no longer needed.
[0038] If so, at 212, method 200 includes redirecting some or all of the network traffic to the client computing device via a second alternative network path evaluated at 208, based at least in part on a path quality indicator indicating that the network traffic does not meet one or more experience criteria. This is shown in Figure 3C where network device 300 has redirected some or all of network traffic 302 from a first network path 308A to a second network path 308B. In other words, at least some of the network traffic that would have been sent using the first network path 308A is sent or relayed between network device 300 and service entity 306 using the second network path 308B by a different set of intermediate network devices. It will be understood that the network device need not redirect all of the network traffic to the second network path. Instead, in cases where the network traffic is destined for multiple client computing devices, at least some of the network traffic may still be directed via the first network path.
[0039] Redirecting some or all of the network traffic via the second network path may at least temporarily provide a better client experience than the first network path, depending on the current network conditions. However, depending on how the network conditions change, and the type and amount of network traffic received from the client computing device, the improved performance provided by the second network path may not continue indefinitely, or the second network path may provide a worse client experience than the first network path. Thus, over time, the network device may receive additional path quality indicators that can be used as a basis for redirecting the network traffic away from the second network path. For example, when some or all of the network traffic is directed via the second network path, the network device may receive a second path quality indicator indicating that the second network path does not meet one or more experience criteria.
[0040] For example, briefly returning Figure 2, at 214, method 200 optionally includes: evaluating whether the client experience is improved due to redirecting some or all network traffic through a second network path. This can be done based on a second path quality indicator provided by the service entity, which will be described in more detail below. If the client experience is not improved, the network device can re-evaluate one or more other potential network paths again at 208, and / or the network device can stop using the second network path and instead send traffic through the first network path. If the client experience has been improved, method 200 proceeds to 214, where the network device continues to direct some or all network traffic through the second network path. In some cases, over time, the network device can increase the portion of network traffic directed through the second network path. Generally, at any time, the network device can re-evaluate the network path currently used to send network traffic to the service entity, and if an alternative path is available and desirable, redirect some or all network traffic through one or more alternative paths.
[0041] In some cases, the network device can receive path quality indicators periodically. For example, after receiving a first path quality indicator, the network device can receive a second path quality indicator after an indicator refresh interval. As an example, the indicator refresh indicator can be 10 minutes, although other suitable intervals can be used.
[0042] If the second path quality indicator indicates that the network traffic directed through the second network path does not meet one or more experience criteria, the network device can redirect the network traffic again. As shown, feedback data from the service entity 306 can be sent to the network repository 312. Before or after the feedback data is sent, it can be pushed through a pipeline for analysis and converted into a second path quality indicator 500, which is stored by the network repository and reflects the quality of the client experience provided by the second network path 308B. As described above for Figures 3A - 3C discussed, the path quality indicator can be directly accessed by the network device in some cases. Alternatively, as Figure 5A shown, the path quality indicator can be read by a separate management plane device, and then the management plane device can change the network device's policy based on the content of the path quality indicator.
[0043] Based on the second path quality indicator, some or all network traffic to the service entity can be redirected again, for example, redirected back to the first network path. This is schematically shown in Figure 5A and Figure 5B . In Figure 5A , the network device 300 receives the second path quality indicator 500, for example, directly or via the management plane device 502. InFigure 5B In this case, based on the second path quality indicator, the network device redirects some or all of the network traffic back to the first network path 308A. For example, this can be done because the second path quality indicator indicates that the experience provided by the second network path does not meet one or more experience criteria. However, in an alternative scenario, the traffic can be redirected back to the first network path based on a path quality indicator that no longer explicitly requests the network traffic to be moved away from the first network path.
[0044] However, in other examples, the network traffic can be redirected to use the first network path for reasons unrelated to the second path quality indicator. For example, the network device can be configured to use the first network path by default, and the first path quality indicator can include a request to redirect the network traffic to use the second path. If the network device stops receiving requests to redirect the network traffic away from the first path, the network device can revert to its default value and continue to use the first network path.
[0045] In some cases, to reduce disruptions to the client experience, the network device can avoid redirecting network traffic over different network paths at a frequency greater than a threshold frequency, or unless there is a reasonable expectation that such a redirect will improve the client experience. Thus, after redirecting network traffic over the second network path, the network device can avoid redirecting the network traffic again until a threshold length of time has elapsed, or unless the network traffic directed over the second network path has lower quality compared to when it was directed over the first network path. This can be determined, for example, based on the second path quality indicator, such as when the second path quality indicator includes raw diagnostic data or a numerical evaluation of the current client experience. In the case where the path quality indicator is a binary value, when the number of negative quality indicators received for the second network path exceeds the number of negative quality indicators received when the network traffic was directed over the first network path, or in other suitable ways, the network device can infer that the performance of the second network path is worse than that of the first network path.
[0046] In Figure 5A and Figure 5B example, the network traffic is redirected from the second network path back to the first network path. However, as discussed above, any number of potential network paths can be available between the service entity and the client computing device. For example, in Figure 6In this case, network device 300 has redirected network traffic 302 from the second network path 308B to the third network path 600, rather than the first network path 308A. Similar to the first and second network paths, the third network path 600 may include any number of intermediate network devices configured to send or relay network traffic between network device 300 and service entity 306. Similarly, the network device may receive additional path quality indicators indicating whether the performance of the third network path meets one or more experience criteria.
[0047] So far, this disclosure has mainly focused on redirecting network traffic based on determining that the current client experience does not meet the experience criteria. However, in other examples, historical experience quality data may also be considered when determining whether to redirect network traffic. For example, as discussed above with respect to Figure 4 the path quality indicators received from one or more sources may be stored in a historical experience quality data set. Thus, when determining whether to redirect network traffic from one network path to another (e.g., from the first network path to the second network path), in addition to the most recently received path quality indicators, the network device may also consider such historical experience quality data.
[0048] For example, the path quality indicator may indicate that the current client experience provided by the first network path does not meet one or more experience criteria. However, the historical experience quality data set may indicate that in previous instances, redirecting some or all of the network traffic to the second network path did not improve the client experience, and / or the performance of the first network path generally improves over time. Thus, the network device may avoid redirecting network traffic away from the first network path.
[0049] In addition, even when the most recently received path quality indicator indicates that the current client experience still meets one or more experience criteria, the historical experience quality data can be used as a basis for preemptively redirecting some or all of the network traffic. As an example, the historical experience quality data set can be used to predict that the performance of a particular network path will degrade at a predicted time. Thus, the network device can redirect network traffic to use a different network path at or before the predicted time. Such analysis can be performed in any suitable manner and, in some cases, may rely on suitable machine learning (ML) or artificial intelligence (AI) techniques. Examples of suitable techniques will be given below with respect to Figure 7 give examples of suitable techniques.
[0050] The methods and processes described herein may be bound to the computing systems of one or more computing devices. Specifically, these methods and processes may be implemented as executable computer applications, network-accessible computing services, application programming interfaces (APIs), libraries, or combinations and / or other computing resources of the foregoing.
[0051] Figure 7 A simplified representation of a computing system 700 is schematically illustrated, which is configured to provide any or all of the computing functions described herein. The computing system 700 may take the form of: one or more personal computers, network-accessible server computers, tablet computers, home entertainment computers, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phones), virtual / augmented / mixed reality computing devices, wearable computing devices, Internet of Things (IoT) devices, embedded computing devices, and / or other computing devices.
[0052] The computing system 700 includes a logic subsystem 702 and a storage subsystem 704. The computing system 700 may optionally include a display subsystem 706, an input subsystem 708, a communication subsystem 710, and / or Figure 7 other subsystems not shown herein.
[0053] The logic subsystem 702 includes one or more physical devices configured to execute instructions. For example, the logic subsystem may be configured to execute instructions that are part of one or more applications, services, or other logical constructs. The logic subsystem may include one or more hardware processors configured to execute software instructions. Additionally or alternatively, the logic subsystem may include one or more hardware or firmware devices configured to execute hardware or firmware instructions. The processors of the logic subsystem may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel, and / or distributed processing. The various components of the logic subsystem may optionally be distributed across two or more separate devices, which may be remotely located and / or configured for cooperative processing. Aspects of the logic subsystem may be virtualized and executed by remotely accessible networked computing devices configured in a cloud computing configuration.
[0054] The storage subsystem 704 includes one or more physical devices configured to temporarily and / or permanently hold computer information such as data and instructions executable by the logic subsystem. When the storage subsystem includes two or more devices, the devices may be co-located and / or remotely located. The storage subsystem 704 may include volatile, non-volatile, dynamic, static, read / write, read-only, random access, sequential access, location-addressable, file-addressable, and / or content-addressable devices. The storage subsystem 704 may include removable and / or built-in devices. When the logic subsystem executes instructions, the state of the storage subsystem 704 may change—for example, to hold different data.
[0055] Aspects of the logic subsystem 702 and the storage subsystem 704 may be integrated together into one or more hardware logic components. For example, such hardware logic components may include program-specific and application-specific integrated circuits (PASIC / ASIC), program-specific and application-specific standard products (PSSP / ASSP), system-on-a-chip (SoC), and complex programmable logic devices (CPLD).
[0056] The logic subsystem and the storage subsystem may cooperate to instantiate one or more logical machines. As used herein, the term "machine" is used to generally refer to a combination of hardware, firmware, software, instructions, and / or any other components that cooperate to provide computer functionality. In other words, a "machine" is never an abstract idea but always has a tangible form. A machine may be instantiated by a single computing device, or a machine may include two or more sub-components instantiated by two or more different computing devices. In some embodiments, a machine includes local components (e.g., software applications executed by a computer processor) that cooperate with remote components (e.g., cloud computing services provided by a network of server computers). The software and / or other instructions that give a particular machine its functionality may optionally be saved as one or more unexecuted modules on one or more suitable storage devices.
[0057] The machine can be implemented using the latest technologies and / or any suitable combination of future machine learning (ML), artificial intelligence (AI), and / or natural language processing (NLP) technologies. Non-limiting examples of technologies that can be incorporated into the implementation of one or more machines include support vector machines, multi-layer neural networks, convolutional neural networks (e.g., including spatial convolutional networks for processing images and / or videos, temporal convolutional neural networks for processing audio signals and / or natural language sentences, and / or any other suitable convolutional neural network configured to convolve and pool features across one or more temporal and / or spatial dimensions), recurrent neural networks (e.g., long short-term memory networks), associative memories (e.g., lookup tables, hash tables, Bloom filters, neural Turing machines, and / or neural random access memories), word embedding models (e.g., GloVe or Word2Vec), unsupervised spatial and / or clustering methods (e.g., nearest neighbor algorithms, topological data analysis, and / or k-means clustering), graphical models (e.g., (hidden) Markov models, Markov random fields, (hidden) conditional random fields, and / or artificial intelligence knowledge bases), and / or natural language processing technologies (e.g., tokenization, stemming, constituency and / or dependency parsing, and / or intent recognition, segmentation models, and / or super-segmentation models (e.g., hidden dynamic models)).
[0058] In some examples, one or more differentiable functions can be used to implement the methods and processes described herein, where the gradient of the differentiable function can be calculated and / or estimated for the input and / or output of the differentiable function (e.g., for training data and / or for an objective function). Such methods and processes can be determined at least in part by a set of trainable parameters. Thus, the trainable parameters for a particular method or process can be adjusted by any suitable training process to continuously improve the functionality of the method or process.
[0059] Non-limiting examples of training processes for adjusting trainable parameters include supervised training (e.g., using gradient descent or any other suitable optimization method), zero-shot, few-shot, unsupervised learning methods (e.g., classification based on categories derived from unsupervised clustering methods), reinforcement learning (e.g., deep Q-learning based on feedback), and / or generative adversarial neural network training methods, belief propagation, RANSAC (random sample consensus), contextual bandit methods, maximum likelihood methods, and / or expectation maximization. In some examples, multiple methods, processes, and / or components of the systems described herein can be trained simultaneously for an objective function that measures the performance of the collective functionality of multiple components (e.g., for enhanced feedback and / or for labeled training data). Training multiple methods, processes, and / or components simultaneously can improve such collective functionality. In some examples, one or more methods, processes, and / or components can be trained independently of other components (e.g., offline training for historical data).
[0060] When included, the display subsystem 706 can be used to present a visual representation of data saved by the storage subsystem 704. This visual representation can take the form of a graphical user interface (GUI). The display subsystem 706 can include one or more display devices using almost any type of technology. In some implementations, the display subsystem can include one or more virtual reality displays, augmented reality displays, or mixed reality displays.
[0061] When included, the input subsystem 708 can include or interface with one or more input devices. The input devices can include sensor devices or user input devices. Examples of user input devices include a keyboard, a mouse, a touch screen, or a game controller. In some embodiments, the input subsystem can include or interface with a selected portion of natural user input (NUI) components. Such component portions can be integrated or peripheral, and the conversion and / or processing of input actions can be on-board or off-board processing. Example NUI component portions can include: a microphone for voice and / or sound recognition; infrared, color, stereo, and / or depth cameras for machine vision and / or gesture recognition; a head tracker, an eye tracker, an accelerometer, and / or a gyroscope for motion detection and / or intent recognition.
[0062] When included, the communication subsystem 710 can be configured to communicatively couple the computing system 700 with one or more other computing devices. The communication subsystem 710 can include wired and / or wireless communication devices compatible with one or more different communication protocols. The communication subsystem can be configured for communication via a personal area network, a local area network, and / or a wide area network.
[0063] This disclosure is presented by way of example and with reference to the related drawings. Components, process steps, and other elements that are substantially the same in one or more of the figures are coordinately identified and described with a minimum of repetition. However, it should be noted that coordinately identified elements may also differ to some extent. It should also be noted that some of the figures may be schematic and not drawn to scale. Deliberate distortions may be made to the various drawing scales, aspect ratios, and number of components shown in the figures to make certain features or relationships more visible.
[0064] In one example, a method for directing network traffic includes: at a network device, receiving network traffic provided by one or more client computing devices; directing the network traffic to a service entity via a first network path; receiving a path quality indicator that indicates whether the network traffic directed via the first network path meets one or more experience criteria; and redirecting some or all of the network traffic to the service entity via a second network path at least based on the path quality indicator indicating that the network traffic directed via the first network path does not meet the one or more experience criteria. In this example or any other example, the path quality indicator is provided by the service entity. In this example or any other example, the path quality indicator is received from a network repository. In this example or any other example, the path quality indicator received from the network repository is derived from information provided by one or both of the service entity and the one or more client computing devices. In this example or any other example, the method further includes: storing the path quality indicator in a historical experience quality data set. In this example or any other example, some or all of the network traffic is redirected via the second network path based on a path redirect request received from the service entity, the path redirect request being generated at least based on the path quality indicator and one or more historical path quality indicators included in the historical experience quality data set. In this example or any other example, the method further includes: analyzing the historical experience quality data set to predict that the performance of the second network path will degrade at a predicted time, and redirecting some or all of the network traffic away from the second network path at or before the predicted time. In this example or any other example, the one or more experience criteria include one or more of the following: detected network latency, detected network jitter, and detected number of packet losses. In this example or any other example, the network traffic includes digital video, and the one or more experience criteria include one or both of the resolution and frame rate of the digital video. In this example or any other example, the method further includes: after redirecting some or all of the network traffic via the second network path, receiving a second path quality indicator that indicates that the network traffic directed via the second network path does not meet the one or more experience criteria, and redirecting some or all of the network traffic to the service entity via a third network path.In this example or any other example, the method further includes: after redirecting some or all of the network traffic through the second network path, receiving a second path quality indicator that indicates that the network traffic directed through the second network path does not meet the one or more experience criteria, and redirecting some or all of the network traffic back to the service entity through the first network path. In this example or any other example, when it is determined that the network traffic has lower quality when directed through the second network path, according to the second path quality indicator, compared to when directed through the first network path, some or all of the network traffic is redirected back to the first network path. In this example or any other example, the method further includes: receiving the second path quality indicator after an indicator refresh interval. In this example or any other example, the indicator refresh interval is 10 minutes.
[0065] In one example, a network device includes: a network communication interface configured to communicatively couple the network device with a service entity and one or more client computing devices; a logic machine; and a storage machine storing instructions executable by the logic machine to: receive network traffic provided by the one or more client computing devices; direct the network traffic to the service entity via a first network path; receive a path quality indicator indicating whether the network traffic directed via the first network path meets one or more experience criteria; and redirect some or all of the network traffic to the service entity via a second network path based at least on the path quality indicator indicating that the network traffic directed via the first network path does not meet the one or more experience criteria. In this example or any other example, the one or more experience criteria include one or more of the following: detected network latency, detected network jitter, and detected packet loss count. In this example or any other example, the instructions may further be executable to: receive a second path quality indicator indicating that the network traffic directed via the second network path does not meet the one or more experience criteria after redirecting some or all of the network traffic via the second network path, and redirect some or all of the network traffic back to the service entity via the first network path. In this example or any other example, the instructions may further be executable to: store the path quality indicator in a historical experience quality data set, and redirect some or all of the network traffic via the second network path based at least on the path quality indicator and one or more historical path quality indicators included in the historical experience quality data set. In this example or any other example, the instructions may further be executable to: analyze the historical experience quality data set to predict that the performance of the second network path will degrade at a predicted time, and redirect some or all of the network traffic away from the second network path at the predicted time or before the predicted time.
[0066] In one example, a method for directing network traffic includes: at a network device, receiving network traffic provided by a plurality of client computing devices; directing the network traffic to the service entity via a first network path; receiving a path quality indicator provided by the service entity, the path quality indicator indicating whether the network traffic directed via the first network path meets one or more experience criteria maintained by the service entity; redirecting some or all of the network traffic to the service entity via a second network path based at least on the path quality indicator indicating that the network traffic directed via the first network path does not meet the one or more experience criteria; receiving a second path quality indicator provided by the service entity, the second path quality indicator indicating whether the network traffic directed via the second network path meets one or more experience criteria maintained by the service entity; and redirecting some or all of the network traffic back to the service entity via the first network path based on determining that the network traffic has lower quality according to the second path quality indicator when directed via the second network path compared to when directed via the first network path.
[0067] It will be understood that the configurations and / or methods described herein are exemplary in nature and that these specific embodiments or examples should not be taken in a limiting sense, as many variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. Accordingly, the various acts illustrated and / or described may be performed in the illustrated and / or described order, in other orders, in parallel, or omitted. Likewise, the order of the above processes may be changed.
[0068] The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various processes, systems, and configurations, as well as other features, functions, acts, and / or properties disclosed herein and any and all equivalents thereof.
Claims
1. A method for directing network traffic, the method comprises: at a network device, receiving network traffic provided by one or more client computing devices; directing the network traffic to a service entity via a first network path; receiving a path quality indicator that indicates whether the client experience provided by directing the network traffic via the first network path meets one or more experience criteria; and at least based on the path quality indicator indicating that the client experience provided by directing the network traffic via the first network path does not meet the one or more experience criteria, redirecting some or all of the network traffic to the service entity via a second network path.
2. The method according to claim 1, wherein, the path quality indicator is provided by the service entity.
3. The method according to claim 1, wherein, the path quality indicator is received from a network repository.
4. The method according to claim 3, wherein, the path quality indicator received from the network repository is derived from information provided by one or both of the service entity and the one or more client computing devices.
5. The method according to claim 1, further comprises: storing the path quality indicator in a historical experience quality data set.
6. The method according to claim 5, wherein, redirecting some or all of the network traffic via the second network path based on a path redirect request received from the service entity, the path redirect request being generated at least based on the path quality indicator and one or more historical path quality indicators included in the historical experience quality data set.
7. The method according to claim 5, further comprises: analyzing the historical experience quality data set to predict that the performance of the second network path will degrade at a predicted time, and redirecting some or all of the network traffic away from the second network path at the predicted time or before the predicted time.
8. The method according to claim 1, wherein, the one or more experience criteria include one or more of the following: detected network latency, detected network jitter, and detected number of packet losses.
9. The method according to claim 1, wherein, the network traffic includes digital video, and the one or more experience criteria include one or both of the resolution and frame rate of the digital video.
10. The method according to claim 1, further comprises: after redirecting some or all of the network traffic via the second network path, receiving a second path quality indicator that indicates that the client experience provided by directing the network traffic via the second network path does not meet the one or more experience criteria, and redirecting some or all of the network traffic to the service entity via a third network path.
11. The method according to claim 1, further comprises: After redirecting some or all of the network traffic over the second network path, a second path quality indicator is received, the second path quality indicator indicating that the client experience provided by directing the network traffic over the second network path does not meet the one or more experience criteria, and some or all of the network traffic is redirected back to the service entity over the first network path.
12. The method according to claim 11, wherein, when it is determined that the network traffic has lower quality when directed over the second network path, according to the second path quality indicator, as compared to when directed over the first network path, some or all of the network traffic is redirected back over the first network path.
13. The method according to claim 1, further comprising: receiving the second path quality indicator after an indicator refresh interval.
14. The method according to claim 13, wherein, the indicator refresh interval is 10 minutes.
Citation Information
Patent Citations
Systems and methods of routing IP telephony data packet communications
WO2014085217A1