Patent Publication Number: US-2023164060-A1

Title: Context-aware path computation and selection

Description:
RELATED APPLICATION 
     This application is a continuation of U.S. application Ser. No. 17/002,491, filed on Aug. 25, 2020, entitled “Context-Aware Path Computation and Selection,” which is a continuation of U.S. application Ser. No. 15/989,077, filed on May 24, 2018 (now U.S. Pat. No. 10,757,011), entitled “Context-Aware Path Computation and Selection,” which is a non-provisional application of U.S. Provisional Patent Application No. 62/511,261, filed May 25, 2017, entitled, “Context-Aware Path Computation and Selection,” each of which are hereby incorporated by reference in their entirety. 
    
    
     FIELD OF THE INVENTION 
     The various embodiments described in this document relate to path computation and selection for a mesh network. In particular, embodiments deliver application or data content across a mesh network of proxy servers by dynamically computing and selecting optimal paths based upon context of the traffic. 
     BRIEF SUMMARY 
     There is a need for apparatuses and methods for selecting a transmission path for network traffic. Such systems and methods optionally complement or replace conventional systems for selecting a transmission path. 
     In accordance with some embodiments, a method includes receiving, by a path management hub, link performance metrics from each of a plurality of proxy server nodes that form a mesh network. Each of the plurality of nodes forms a portion of the mesh network via a link to each of two or more other nodes within the plurality of nodes. The link performance metrics represent a plurality of performance metric types. The method also includes evaluating, by the path management hub in response to receiving the link performance metrics, a plurality of potential paths between respective first and second nodes within the plurality of nodes using the received link performance metrics to determine optimal paths for each of a plurality of metric types and/or a combination of metric types. The method also includes determining, by the path management hub, a context representing one or more link performance metric types to be given preference for a service. The method also includes mapping, by the path management hub, a service identifier for the service to a plurality of the determined optimal paths between the first node and second nodes using the one or more link performance metric types of the determined context. The method also includes transmitting, from the path management hub to the first node, a respective next hop for each of the plurality of mapped optimal paths and the mapping between each respective next hop and the service identifier. The method also includes receiving, by the first node from the path management hub, the service identifier mapped to a plurality of next hops for the plurality of mapped optimal paths. The method also includes receiving, by the first node, traffic for a first connection with the service. The method also includes selecting, by the first node in response to determining the received traffic is for the service, a first next hop mapped to the service identifier of the plurality of next hops for the plurality of mapped optimal paths. The method also includes forwarding, by the first node, the received traffic to the selected first next hop. 
     In some embodiments, the method also includes tracking, by the first node, link performance metrics for traffic for the service via each of the plurality of next hops. The method also includes determining, by the first node, using the link performance metrics tracked by the first node, that a second next hop mapped to the service identifier of the plurality of next hops received from the path management hub outperforms the first next hop in at least one of the tracked performance metrics. The method also includes receiving, by the first node, traffic for a second connection with the service. The method also includes forwarding, by the first node in response to determining the second next hop outperforms the first next hop, the received traffic for the second connection with the service to the second next hop. 
     In some embodiments, the method also includes transmitting, by the first node to the path management hub, an indication of the first node using the second next hop to forward traffic for the service and the tracked link performance metrics. 
     In some embodiments, the method also includes tracking, by the first node, link performance metrics for traffic for the service via each of the plurality of next hops, wherein the link performance metrics tracked by the first node include, for each connection, bytes directed to the service over a period of time and bytes received from the service over a period of time. The method also includes determining, by the first node, using the link performance metrics tracked by the first node, that a ratio of bytes directed to the service to bytes received from the service is above a first threshold value. The method also includes receiving, by the first node, traffic for a second connection with the service. The method also includes, in accordance with a determination that the ratio is above the first threshold value, forwarding, by the first node, the received traffic for the second connection with the service to a second next hop. 
     In some embodiments, the method also includes tracking, by the first node, link performance metrics for traffic for the service via each of the plurality of next hops, wherein the link performance metrics tracked by the first node include, for each connection, bytes directed to the service over a period of time and bytes received from the service over a period of time. The method also includes determining, by the first node using the link performance metrics tracked by the first node, whether a ratio of bytes directed to the service to bytes received from the service meets first reordering criteria. The method also includes receiving, by the first node, traffic for a second connection with the service. The method also includes, in accordance with a determination that the ratio of bytes directed to the service to bytes received from the service meets the first reordering criteria, forwarding, by the first node, the received traffic for the second connection with the service to a second next hop. 
     In some embodiments, the method also includes tracking, by the first node, link performance metrics for traffic for the first connection for the service via the first next hop. The method also includes determining, by the first node using the link performance metrics tracked by the first node, that at least one of the link performance metrics for the first connection is above a second threshold value. The method also includes receiving, by the first node, traffic for a second connection with the service. The method also includes, in accordance with a determination that the at least one link performance metric for the first connection is above the second threshold value, forwarding, by the first node, the received traffic for the second connection with the service to the second next hop. 
     In some embodiments, the method also includes tracking, by the first node, link performance metrics for traffic for the first connection for the service via the first next hop. The method also includes determining, by the first node using the link performance metrics tracked by the first node, that at least one of the link performance metrics for the first connection meets second reordering criteria. The method also includes receiving, by the first node, traffic for a second connection with the service. The method also includes, in accordance with a determination that the at least one link performance metric for the first connection meets the second reordering criteria, forwarding, by the first node, the received traffic for the second connection with the service to the second next hop. 
     In some embodiments, the link performance metrics include, for each connection, bytes directed to each service over a period of time and bytes received from each service over a period of time. The method also includes determining, by the path management hub using the link performance metrics, whether a ratio of bytes directed to the service to bytes received from the service is above a third threshold value. The method also includes, in accordance with a determination that the ratio of bytes directed to the service to bytes received from the service is above the third threshold value, selecting, by the path management hub, the context representing one or more link performance metric types. 
     In some embodiments, the link performance metrics include, for each connection, bytes directed to each service over a period of time and bytes received from each service over a period of time. The method also includes determining, by the path management hub using the link performance metrics, whether a ratio of bytes directed to the service to bytes received from the service meets context adjustment criteria. The method also includes, in accordance with a determination that the ratio of bytes directed to the service to bytes received from the service meets the context adjustment criteria, selecting, by the path management hub, the context representing one or more link performance metric types. 
     In some embodiments, the service identifier mapped to the next hops for the plurality of optimal paths transmitted from the path management hub to the first node includes a mapping to the context representing the one or more link performance metric types. 
     In some embodiments, the plurality of link performance metric types includes one or more of: bandwidth, requests per second, packet loss, jitter, and latency. 
     In some embodiments, determining the context representing the one or more link performance metric types to be given preference for the service includes receiving, by the path management hub, a selection of the context. 
     In accordance with some embodiments, a non-transitory computer-readable medium stores instructions, which when executed by a processing device, cause the processing device to perform a method. The method includes receiving, by a path management hub, link performance metrics from each of a plurality of proxy server nodes that form a mesh network. Each of the plurality of nodes forms a portion of the mesh network via a link to each of two or more other nodes within the plurality of nodes. The link performance metrics represent a plurality of performance metric types. The method also includes evaluating, by the path management hub in response to receiving the link performance metrics, a plurality of potential paths between respective first and second nodes within the plurality of nodes using the received link performance metrics to determine optimal paths for each of a plurality of metric types and/or a combination of metric types. The method also includes determining, by the path management hub, a context representing one or more link performance metric types to be given preference for a service. The method also includes mapping, by the path management hub, a service identifier for the service to a plurality of the determined optimal paths between the first node and second nodes using the one or more link performance metric types of the determined context. The method also includes transmitting, from the path management hub to the first node, a respective next hop for each of the plurality of mapped optimal paths and the mapping between each respective next hop and the service identifier. The method also includes receiving, by the first node from the path management hub, the service identifier mapped to a plurality of next hops for the plurality of mapped optimal paths. The method also includes receiving, by the first node, traffic for a first connection with the service. The method also includes selecting, by the first node in response to determining the received traffic is for the service, a first next hop mapped to the service identifier of the plurality of next hops for the plurality of mapped optimal paths. The method also includes forwarding, by the first node, the received traffic to the selected first next hop. 
     In some embodiments, the instructions cause the processing device to track, by the first node, link performance metrics for traffic for the service via each of the plurality of next hops. The instructions also cause the processing device to determine, by the first node, using the link performance metrics tracked by the first node, that a second next hop mapped to the service identifier of the plurality of next hops received from the path management hub outperforms the first next hop in at least one of the tracked performance metrics. The instructions also cause the processing device to receive, by the first node, traffic for a second connection with the service. The instructions also cause the processing device to forward, by the first node in response to determining the second next hop outperforms the first next hop, the received traffic for the second connection with the service to the second next hop. 
     In some embodiments, the instructions also cause the processing device to transmit, by the first node to the path management hub an indication of the first node using the second next hop to forward traffic for the service and the tracked link performance metrics. 
     In some embodiments, the instructions also cause the processing device to track, by the first node, link performance metrics for traffic for the service via each of the plurality of next hops. The link performance metrics tracked by the first node include, for each connection, bytes directed to the service over a period of time and bytes received from the service over a period of time. The instructions also cause the processing device to determine, by the first node using the link performance metrics tracked by the first node, a ratio of bytes directed to the service to bytes received from the service meets first reordering criteria. The instructions also cause the processing device to receive, by the first node, traffic for a second connection with the service. The instructions also cause the processing device to, in accordance with a determination that the ratio of bytes directed to the service to bytes received from the service meets the reordering criteria, forward, by the first node, the received traffic for the second connection with the service to the second next hop. 
     In some embodiments, the instructions also cause the processing device to track, by the first node, link performance metrics for traffic for the first connection for the service via the first hop. The instructions also cause the processing device to determine, by the first node using the link performance metrics tracked by the first node, that at least one of the link performance metrics for the first connection meets second reordering criteria. The instructions also cause the processing device to receive, by the first node, traffic for a second connection with the service. The instructions also cause the processing device to, in accordance with a determination that the at least one link performance metric for the first connection meets the second reordering criteria, forward, by the first node, the received traffic for the second connection with the service to the second next hop. 
     In some embodiments, the link performance metrics include, for each connection, bytes directed to each service over a period of time and bytes received from each service over a period of time. The instructions also cause the processing device to determine, by the path management hub using the link performance metrics, whether a ratio of bytes directed to the service to bytes received from the service meets context adjustment criteria. The instructions also cause the processing device to, in accordance with a determination that the ratio of bytes directed to the service to bytes received from the service meets the context adjustment criteria, selecting, by the path management hub, the context representing one or more link performance metric types. 
     In some embodiments, the service identifier mapped to the next hops for the plurality of optimal paths transmitted from the path management hub to the first node includes a mapping to the context representing the one or more link performance metric types. 
     In some embodiments, the plurality of link performance metric types includes one or more of: bandwidth, requests per second, packet loss, jitter, and latency. 
     In some embodiments, determining the context representing the one or more link performance metric types to be given preference for the service includes receiving, by the path management hub, a selection of the context. 
     In accordance with some embodiments, a system comprises a path management hub including a first processing device and a first memory coupled to the first processing device. The first memory stores instructions which, when executed by the first processing device, cause the path management hub to receive link performance metrics from each of a plurality of proxy server nodes that form a mesh network. Each of the plurality of nodes forms a portion of the mesh network via a link to each of two or more other nodes within the plurality of nodes. The link performance metrics represent a plurality of performance metric types. The instructions of the first memory also cause the path management hub to evaluate, in response to receiving the link performance metrics, a plurality of potential paths between respective first and second nodes within the plurality of nodes using the received link performance metrics to determine optimal paths for each of a plurality of metric types and/or a combination of metric types. The instructions of the first memory also also cause the path management hub to determine a context representing one or more link performance metric types to be given preference for a service. The instructions of the first memory also also cause the path management hub to map a service identifier for the service to a plurality of the determined optimal paths between the first node and second nodes using the one or more link performance metric types of the determined context. The instructions of the first memory also also cause the path management hub to transmit, to the first node: a respective next hop for each of the plurality of mapped optimal paths and the mapping between each respective next hop and the service identifier. The first node includes a second processing device and a second memory coupled to the second processing device. The second memory stores instructions which, when executed by the second processing device, cause the first node to receive, from the path management hub, the service identifier mapped to a plurality of next hops for the plurality of mapped optimal paths. The instructions of the second memory also cause the first node to receive traffic for a first connection with the service. The instructions of the second memory also cause the first node to select, in response to determining the received traffic is for the service, a first next hop mapped to the service identifier of the plurality of next hops for the plurality of mapped optimal paths. The instructions of the second memory also cause the first node to forward the received traffic to the selected first next hop. 
     In some embodiments, execution of the instructions stored in the second memory further cause the first node to track link performance metrics for traffic for the service via each of the plurality of next hops. The instructions stored in the second memory also cause the first node to determine, using the link performance metrics tracked by the first node, that a second next hop mapped to the service identifier of the plurality of next hops received from the path management hub outperforms the first next hop in at least one of the tracked performance metrics. The instructions stored in the second memory also cause the first node to receive traffic for a second connection with the service. The instructions stored in the second memory also cause the first node to forward, in response to determining the second next hop outperforms the first next hop, the received traffic for the second connection with the service to the second next hop. 
     In accordance with some embodiments, a computer-implemented method comprises receiving, by a path management hub, link performance metrics from each of a plurality of proxy server nodes that form a mesh network. Each of the plurality of nodes forms a portion of the mesh network via a link to each of two or more other nodes within the plurality of nodes. The link performance metrics represent a plurality of performance metric types. The method also includes evaluating, by the path management hub in response to receiving the link performance metrics, a plurality of potential paths between respective first and second nodes within the plurality of nodes using the received link performance metrics to determine optimal paths for each of a plurality of metric types and/or a combination of metric types. The method also includes determining, by the path management hub, a context representing one or more link performance metric types to be given preference for a service. The method also includes mapping, by the path management hub, a service identifier for the service to a plurality of the determined optimal paths between the first node and second nodes using the one or more link performance metric types of the determined context. The method also includes transmitting, from the path management hub to the first node a respective next hop for each of the plurality of mapped optimal paths, and the mapping between each respective next hop and the service identifier. 
     BACKGROUND OF THE INVENTION 
     Content delivery networks (CDNs) aim to serve content to end-users with high availability and high performance. In particular, CDNs deploy proxy servers in multiple, geographically diverse data centers to cache and serve the content. When the content is requested, the request is directed to the node that, e.g., will require the fewest hops, is the least number of network seconds away from the client requesting the content, etc. Typically, this results in the selection of an edge node that is closest to the client. For example, a proxy server within a telecommunications service provider (TSP) network may cache and serve content to customers of the TSP to lessen demands on the network backbone and quickly and reliably deliver the content. Caching content in many locations to maximize the chances of having a proxy server close to any given client, however, can incur significant costs. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which: 
         FIG.  1    illustrates, in block diagram form, an exemplary mesh network of proxy servers implementing context-aware path computation; 
         FIG.  2    is a flow chart illustrating an exemplary method of context-aware path computation and selection; and 
         FIGS.  3 - 6    illustrate exemplary traffic flows used to determine a context representing one or more link performance metric types to be given preference for a service. 
     
    
    
     DETAILED DESCRIPTION 
     This document describes embodiments that deliver application or data content across a mesh network of proxy servers by dynamically computing and selecting optimal paths based upon context of the traffic. Optimal paths are selected by a path management hub using link performance metrics received from proxy server nodes that make up the mesh network and based upon a service-based context. The path management hub can be implemented as a single server or distributed system in a location or across multiple locations. Each service-based context represents one or more link performance metric types to be given preference for that service. In some embodiments, an administrator for the service provides a selection of a particular context. In some embodiments, the hub sets the context to a default setting or based upon an evaluation of traffic flow patterns for the service. As an example of selecting optimal paths, the path management hub may calculate directed graphs using various performance metrics of links along potential paths through the mesh network and select multiple paths as optimal based upon each service-based context. The path management hub maps the context-based optimal paths to the corresponding service. 
     Once optimal paths are selected and mapped, the path management hub distributes next hop information to the nodes. In some embodiments, a node receiving traffic for a given service uses the mapping to select a next hop provided by the path management hub and forward the traffic to that next hop. In some embodiments, one or more nodes track link performance metrics to report back to the path management hub. In some embodiments, nodes use the tracked link performance metrics to select among multiple next hops mapped to a single service. 
     As a result, embodiments reduce the number of locations needed to cache content or host applications in order to provide high performance. Instead, embodiments achieve high performance in delivering application or data content using intelligent selection of paths through the mesh of proxy servers. Additionally, embodiments utilize out-of-band path selection based upon a hub&#39;s global view of the mesh network as well as in-band selection based upon an individual node&#39;s evaluation of performance metrics. 
       FIG.  1    illustrates, in block diagram form, exemplary mesh network  100  of proxy server nodes  105  (e.g., nodes  105   a,    105   b,    105   c,    105   d,    105   e,    105   f,    105   g,    105   h,    105   i,    105   j,    105   k,  and  105   l ) implementing context-aware path computation. In some embodiments, mesh network  100  is a content delivery network (CDN) and/or application delivery network (ADN). Mesh network  100  includes a geographically distributed set of proxy server nodes  105  deployed in multiple data centers. Mesh network  100  may include more or fewer nodes  105  than illustrated. 
     In some embodiments, a respective node  105  (e.g., as illustrated by node  105   a ) includes hardware  110 . Hardware  110  includes one or more processors (“CPU(s)”), data storage and memory (e.g., “RAM”), and network interface controllers (“NIC(s)”). The data storage and memory may be used for storing data, metadata, and programs (e.g., link evaluation module  115 , DNS module  120 , forwarding module  125 , and/or path computation module  130 ) for execution by the processor(s). In some embodiments, the data storage and memory may include one or more of volatile and non-volatile memories, such as Random Access Memory (“RAM”), Read Only Memory (“ROM”), a solid state disk (“SSD”), Flash, Phase Change Memory (“PCM”), and/or other types of data storage, such as magnetic disk drives, optical disk drives, etc. In some embodiments, the memory includes internal and/or distributed memory. In some embodiments, one or more buses (not shown) interconnect the various components of hardware  110 . In some embodiments, NIC(s) connect one more of nodes  105  (e.g., nodes  105   a - 105   l ), via a wired and/or wireless network, with other nodes  105 , client devices external to mesh network  100 , and/or server devices external to mesh network  100 . 
     In some embodiments, a respective node (e.g., as illustrated by node  105   a ) includes multiple modules. Each of these modules may be embodied in hardware, software, or a combination of hardware and software. Link evaluation module  115  tracks metrics between nodes  105  (e.g., nodes  105   a - 105   l ). For example, link evaluation module  115  of a first node may track bytes transmitted through the first node to a service per second per connection and bytes received by the first node from a service per second per connection. In some embodiments, these metrics provide a representation of the data flow characteristics during a connection between a client and the service. Exemplary data flow characteristics are described in further detail with reference to  FIGS.  3 - 6   . In some embodiments, link evaluation module  115  tracks other metric types, including one or more of requests per second per connection, incoming packet loss per network address, outgoing packet loss per network address, latency per network address, bandwidth per network address, jitter per network address, network utilization, traffic content (e.g., by inspecting a header, packet, or other data/metadata in transit), latency of various requests and/or responses (e.g., requests and/or responses for HTML pages, JavaScript, CSS, images, APIs and/or media), etc. 
     Link evaluation module  115  stores tracked metrics in data storage or memory within hardware  110 . Additionally, link evaluation module  115  transmits the tracked metrics to a path management hub using NIC(s) within hardware  110 . In some embodiments, link evaluation module  115  maps one or metrics to a service for the corresponding traffic. For example, link evaluation module  115  may maintain a data structure within the data storage or memory that maps an identifier for a service to metrics for traffic coming from and/or going to the service. Exemplary services include providing content for a website, streaming video, providing data for an application, etc. 
     In some embodiments, link evaluation module  115  injects test traffic to track metrics between a first respective node  105  (e.g., node  105   a ) and each of a plurality of second nodes  105  (e.g., nodes  105   b - 105   l ). For example, each respective node  105  may store a list of network addresses of other nodes  105  and data for test transmissions. Transmitting test traffic to and receiving responses from other nodes  105  enables link evaluation module  115  to track metrics for links to other nodes  105  in addition to or instead of tracking actual traffic directed to and received from one or more services. 
     In some embodiments, link evaluation module  115  uses the tracked link performance metrics to select a next hop for traffic, e.g., as described in greater detail with reference to  FIGS.  2 - 6   . 
     In some embodiments, a respective node  105  (e.g., as illustrated by node  105   a ) is includes domain name system (DNS) module  120 . DNS module  120  stores next hop information. For example, respective nodes  105  may determine respective neighboring nodes  105  and track the next hop for traffic using an address discovery protocol. In some embodiments, next hop information is provided by a path management hub. For example, as described in greater detail herein, a path management hub may determine optimal paths per service and distribute next hop information to nodes  105  for those paths. Next hop information for a service may include a list of optimal next hops mapped to the service in ranked order. In some embodiments, link evaluation module  115  adjusts the ranked order of next hops based upon the tracked link performance metrics, e.g., as described in greater detail with reference to  FIGS.  2 - 6   . 
     In some embodiments, a respective node  105  (e.g., as illustrated by node  105   a ) includes forwarding module  125 . Forwarding module  125  receives traffic from a client, service, or another node  105 , determines a service and/or destination from the received traffic, and/or selects the next hop using the mapping stored by DNS module  120 . 
     In some embodiments, a node  105  (e.g., node  105   a ) includes path computation module  130 . In some embodiments, a node that includes path computation module  130  serves as a path management hub for mesh network  100 . For example, mesh network  100  may have one active path management hub that computes and distributes optimal paths to nodes  105 . 
     In some embodiments, path computation module  130  maintains a registry of nodes  105  within mesh network  100 . In some embodiments, path computation module  130  receives link performance metrics from each of nodes  105  and determines optimal paths between nodes  105  for each of a plurality of metric types or a combination of metric types using the received link performance metrics. In some embodiments, path computation module  130  maps a service identifier to a plurality of the determined optimal paths for a context representing one or more link performance metric types and transmits a next hop for each of the plurality of mapped optimal paths, along with the mapping of the service(s) to the next hops, to one or more nodes. In some embodiments, path computation module  130  maps a context or link performance metric type to one or more of the next hops and transmits that mapping to one or more nodes. Path computation module  130 , as implemented within a path management hub, is described in greater detail with reference to  FIGS.  2 - 6   . 
       FIG.  2    is a flow chart illustrating exemplary method  200  of context-aware path computation and selection. At block  205 , the path management hub receives link performance metric data from nodes  105  within mesh network  100 . For example, mesh network  100  is illustrated as including twelve nodes  105   a - 105   l,  one of which (e.g., node  105   a ) serves as path management hub via the active use of path computation module  130 . Each link evaluation module  115  of each respective node  105  tracks and transmits link performance metrics for actual and/or test traffic transmitted and/or received by that respective node  105  and transmits the link performance metrics to the path management hub. In some embodiments, the path management hub receives the link performance metrics at a regular interval for each node  105  (e.g., as defined by periods of time, number of connections evaluated, etc.). The path management hub receives the link performance metrics, e.g., via a client/server communication(s) with each respective node  105  and/or via a message queue. Received link performance metrics include one or more of: bytes transmitted through the node to a service per second per connection, bytes received by the node from a service per second per connection, an indication of a type of data flow during a connection between a client and the service as represented by the bytes transmitted/received, requests per second per connection, incoming packet loss per network address, outgoing packet loss per network address, latency per network address, bandwidth per network address, jitter per network address, network utilization, traffic content type (e.g., by inspecting a header, packet, or other data/metadata in transit), context/link performance metric type for a service as determined by a respective node  105 , etc. In some embodiments, the link performance metrics are mapped to one or more of: a service, a period of time, a source address or other identifier, and a destination address or other identifier. 
     At block  210 , the path management hub determines a context representing one or more link performance metric types for each service utilizing mesh network  100 . In some embodiments, a context indicates that traffic to and/or from a service is bandwidth sensitive. In such embodiments, the path management hub will prioritize paths through mesh network  100  that provide the best performance for bandwidth. In some embodiments, a context may indicate that traffic to and/or from a service is latency sensitive. In such embodiments, the path management hub will prioritize paths through mesh network  100  that provide the best performance for latency. A context may represent multiple link performance metric types. For example, a context may indicate that traffic to and/or from a service is latency and cost sensitive. In such an example, the path management hub will prioritize paths through mesh network  100  that provide the best performance for latency while also being cost effective and/or not exceeding a cost threshold. Contexts are not limited to these examples and may represent another link performance metric type or a combination of link performance metric types. 
     The path management hub determines a context for a service by looking up a stored mapping between the service and the context or otherwise making a determination based upon data received from nodes  105 . For example, the path management hub may receive and store a preferred context from an administrator or other representative of the service seeking to have content or application delivered via mesh network  100 . Alternatively, the path management hub may receive and store a preferred context as determined by a node  105 . As another alternative, the path management hub&#39;s determination includes determining that there is no preconfigured context and setting the context to a default setting. 
     In some embodiments, the path management hub determines context based upon a node  105 , identifying a traffic type by parsing the traffic header/metadata and/or traffic payload data and transmitting the traffic type to the path management hub. For example, the path management hub may receive from a node  105  a mapping between an identifier for a service and a traffic type for that service as determined by the node  105 . Traffic types may label the content, e.g., image, audio, video, application programming interface (API) requests and/or responses, voice over internet protocol (VOIP) calls, etc. Alternatively, traffic types received from nodes  105  may categorize the traffic. For example, a node  105  may categorize images and API requests and/or responses as latency sensitive traffic, streaming video as bandwidth sensitive, VOIP calls as jitter sensitive, etc. 
     In some embodiments, the path management hub determines context based upon data flow patterns detected by a node  105 . For example, nodes  105  may track data flow, e.g., as described with reference to  FIGS.  3 - 6   , and transmit to the path management hub a mapping between an identifier for a service and a traffic type based upon the tracked data flow. For example, a node  105  may categorize traffic flows as latency sensitive traffic, bandwidth sensitive, jitter sensitive, etc. based upon bytes transmitted through the node to a service per second per connection, bytes received by the node from a service per second per connection, incoming packet volume, outgoing packet volume, symmetry between incoming and outgoing traffic, etc. 
     At block  215 , the path management hub calculates or otherwise determines one or more optimal paths for each link performance metric type. For example, in response to receiving the link performance networks, the path management hub utilizes the received link performance metrics to assign values to each link between two nodes  105  within mesh network  100 . For each link performance metric type, the path management hub calculates directed graphs between nodes  105  using the values for that performance metric type as inputs to Dijkstra&#39;s algorithm or another algorithm for determining the shortest path between nodes  105 . 
     In some embodiments, the path management hub determines one or more optimal paths for a combination of link performance metric types. For example, the path management hub may utilize multiple link performance metric types to assign values to each link between two nodes  105 . In some embodiments, utilizing multiple performance metric types includes creating a multidimensional value in which each dimension represents a performance metric type. In some embodiments, utilizing multiple performance metric types includes calculating a sum, product, or other combination of the performance metrics of each type for each link. In some embodiments, utilizing multiple performance metric types includes calculating a shortest path for a first performance metric type that does not exceed or does not fall below a threshold for a second performance metric type. 
     In some embodiments, assigning values to each link includes normalizing the received link performance metrics. Normalizing the received link performance metrics may include adjusting values based upon whether a high value or a low value is optimal for a given link performance metric type. For example, the shortest path for latency is based upon links with low latency while the shortest path for bandwidth is based upon links with high bandwidth. Additionally, normalizing the received link performance metrics may include weighting link performance metrics based upon link performance metric type. 
     In some embodiments, in determining optimal paths, the path management ranks multiple paths between nodes  105  for each link performance metric type. For example, the path management hub may determine the top two or three optimal paths between two nodes  105 . If a service may be provided by multiple nodes  105  (e.g., using cached content at each of multiple nodes  105  or each of multiple nodes  105  may serve as a point of ingress/egress for an origin of a given service), the path management hub may determine the top two or three optimal paths between a first node  105  and one of the multiple other nodes. Alternatively, the path management hub determines a single optimal path between each set of two nodes  105 . 
     At block  220 , the path management hub maps a service identifier for each service to one or more of the optimal paths based upon the determined context for that service. For example, if the determined context for a service indicates a preference for high bandwidth paths, the path management hub maps an identifier for that service to the path(s) determined to be optimal for bandwidth. In an embodiment in which multiple optimal paths are determined for a context, the path management hub maps the identifier to a ranked list of the optimal paths. A service identifier is a port number, network address, combination of port number and network address, or another unique identifier for a service. 
     In some embodiments, the path management hub utilizes a context to map a service identifier to multiple optimal paths, each path selected as being optimal for a different link performance metric type. For example, a default context may be utilized to map a service identifier to a list including an optimal path for bandwidth, an optimal path for latency, and an optimal path for jitter. Using a determined traffic type (e.g., based upon traffic flow or inspection, as described herein), nodes  105  may select an optimal path that corresponds to the traffic type. For example, for a traffic type that is bandwidth sensitive, node  105  selects the optimal path for bandwidth. 
     Additionally, the path management hub distributes next hop information of the mapped optimal paths to nodes  105 . For example, optimal paths may include intermediate nodes  105  between a first node  105  forwarding traffic and a second node  105  receiving the traffic. The path management hub determines the next hop along each optimal path for each node  105  for each service and transmits a mapping of a service identifier to one or more next hops for the context determined to apply to that service. In some embodiments, the path management hub includes a mapping of a context or link performance metric type the next hops when distributed to nodes  105   
     At block  225 , each node  105  receives next hop information from the path management hub. For example, for each service, a first node  105  receives an identifier for the service mapped to a ranked list of next hops representing other nodes  105  to which the first node is to forward traffic for the service. In some embodiments, the ranked list is mapped to both a service and a context. In some embodiments, the ranked list is mapped to a service and each next hop within the ranked list is mapped to a context. DNS module  120  stores the mapped ranked list. 
     At block  230 , node  105  receives network traffic and forwards the traffic using the received next hop information. For example, forwarding module  125  receives network traffic that includes a domain, source address, destination address, port number, a combination of an address and port number, and/or another unique identifier associated with a service. Using the service identifier, DNS module  120  selects a next hop. In an embodiment in which node  105  receives a ranked list of next hops mapped to a service identifier, DNS module  120  selects the top ranked next hop in the list and forwarding module  125  forwards the traffic to the node  105  at the next hop. 
     At block  235 , node  105  tracks link performance metrics. In some embodiments, link evaluation module  115  injects test traffic to track metrics between a first node  105  and each of a plurality of second nodes  105 . For example, each node  105  may store a list of network addresses of other nodes  105  and data for test transmissions. In some embodiments, the stored list of network addresses is the collection of next hops received from the path management hub. Transmitting test traffic to and receiving responses from other nodes  105  enables link evaluation module  115  to track metrics (e.g., one or more of the plurality of link performance metric types described in this document) for links to other nodes  105  in addition to or instead of tracking actual traffic directed to and received from one or more services. In some embodiments, link evaluation module  115  transmits and receives test traffic via forwarding module  125  in response to the expiration of a regular time interval, the completion of a threshold number of connections, or at another interval/threshold. 
     Node  105  transmits tracked link performance metrics to the path management hub. In some embodiments, link evaluation module  115  transmits tracked link performance metrics to the path management hub upon completion of evaluation a batch of links. In some embodiments, link evaluation module  115  transmits tracked link performance metrics as determined. 
     Link evaluation module  115  optionally reorders next hop information stored by DNS module  120  based upon tracked link performance metrics. As a result of such a reordering, node  105  makes internal/in-band adjustments to the optimal paths in between external/out-of-band adjustments to the optimal paths made by the path management hub. For example, link evaluation module  115  may determine, using the tracked link performance metrics, that the top ranked next hop as determined by the path management hub is no longer the optimal path for a given context. As a specific example, the next hop info received by node  105  indicates that a service is mapped to a context configured to prioritized bandwidth and three next hops based upon the context. In response to link evaluation module  115  determining that tracked link performance metrics demonstrate that the second next hop in the ranked list outperforms the first next hop in the ranked list in bandwidth, link evaluation module reorders the ranked list to promote the second next hop to first. 
     In some embodiments, link evaluation module  115  makes the determination to reorder the ranked list of next hops for a service by determining which link performance metric(s) to use to evaluate a ranked list of next hops for a given service. For example, a context identifier received from the path management hub along with the service and mapped next hops for the service may be resolved by link evaluation module  115  as representing one or more link performance metrics. 
     In some embodiments, link evaluation module  115  makes the determination to reorder the ranked list of next hops for a service by inspecting traffic for that service. For example, by inspecting a header, packet, or other data/metadata in transit, link evaluation module  115  determines a traffic type for that service. Traffic types may label the content, e.g., image, audio, video, application programming interface (API) requests and/or responses, voice over internet protocol (VOIP) calls, etc. and/or map the traffic type to a context/link performance metric type. Link evaluation module  115  reorders the ranked list of next hops if any lower ranked next hop outperforms a higher ranked next hop in the tracked link performance metric of the determined link performance metric type for the traffic. 
     In some embodiments, the ranked list may include next hops that prioritize different contexts or link performance metric types. In such an embodiment, link evaluation module  115  reorders the ranked list of next hops if any lower ranked next hop prioritizes the determined link performance metric type for the traffic and the top ranked next hop does not. 
     In some embodiments, link evaluation module  115  makes the determination to reorder the ranked list of next hops for a service based upon estimating the load upon a link, node  105 , or service. For example, a service may be provided by multiple origin servers coupled to different nodes  105  or by different nodes  105  as proxies. The tracked link performance metrics may provide an indication of a path, node  105 , or origin that is less loaded and/or a path, node  105 , or origin that has exceeded a threshold load value. In response to determining there is a less loaded option or in response to determining the top ranked next hop is an option that exceeds a load threshold, link evaluation module  115  reorders the ranked list to provide load balancing, throttle traffic, etc. 
     In some embodiments, link evaluation module  115  makes the determination to reorder the ranked list of next hops for a service by characterizing traffic flow data for the service. For example, traffic flows may be characterized as corresponding to a context or one or more link performance metric types. The context or link performance metric type(s) may be used to evaluate the link performance metrics and reorder next hops as described above. 
     Method  200  continues, in parallel, to block  205  and block  230 . The path management hub receives updated link performance metrics from nodes  105  and updates optimal paths and the corresponding next hop information as described with reference to blocks  205  through  220 . Additionally, in the meantime, the node  105  continues to receive and forward traffic, track link performance metrics, and optionally reorder next hops as described with reference to blocks  230  and  235 . 
       FIGS.  3 - 6    illustrate exemplary traffic flows used to determine a context representing one or more link performance metric types to be given preference for a service. For example, link evaluation module  115  may track as a part of the link performance metrics, per connection, bytes transmitted per second through the node to a service and/or bytes received per second by the node from a service. Link evaluation module  115  may perform determinations as described with regard to  FIGS.  3 - 6    to determine whether next hop reordering criteria and/or context adjustment criteria are met. 
       FIG.  3    illustrates an exemplary traffic flow for request(s) and response(s) for files. For example, a service may provide one or more Cascading Style Sheets (CSS), JavaScript, HyperText Markup Language (HTML) files, images, or other files. As illustrated, the traffic flow for requests and responses for such files may result in relatively small amounts of bytes per second in and out. Additionally, the illustrated traffic flow of such files demonstrates a relatively equal ratio of bytes in as compared to bytes out. Using the volume and/or ratio of bytes in and out, link evaluation module  115  determines that the next hop for the traffic should prioritize latency. For example, link evaluation module  115  determines that the volume of bytes in and/or volume of bytes out (and/or ratio of bytes in to bytes out) meets reordering criteria (e.g., a volume of byes out is below a threshold value and/or a ratio of bytes in to bytes out is within a predefined range of ratio values) and, thus, maps to a context that prioritizes latency. 
       FIG.  4    illustrates an exemplary traffic flow for request(s) and response(s) for a streaming service. The illustrated traffic flow shows relatively small amounts of bytes per second in and larger amounts of bytes per second out. Using the volume of bytes out and/or ratio of bytes per second in to bytes per second out, link evaluation module  115  determines that the next hop for the traffic should prioritize bandwidth. For example, link evaluation module  115  determines that reordering criteria are met when, for example, the volume of bytes out is above a threshold value and/or a ratio of bytes in to bytes out (e.g., over a predetermined time period) is below a threshold ratio and, thus, maps to a context that prioritizes bandwidth. 
       FIG.  5    illustrates an exemplary traffic flow for request(s) and response(s) for a streaming service that transmits data in a chunked manner. Similar to  FIG.  4   , the illustrated traffic flow shows relatively small amounts of bytes per second in and larger amounts of bytes per second out. Using the volume and/or ratio of bytes in and out, link evaluation module  115  determines that the next hop for the traffic should prioritize bandwidth. For example, link evaluation module  115  determines that reordering criteria are met when, for example, the volume of bytes out is above a threshold value and/or a ratio of volume of bytes in to bytes out (e.g., over a predetermined time period) is below a threshold ratio and, thus, maps to a context that prioritizes bandwidth. 
       FIG.  6    illustrates an exemplary traffic flow for request(s) and response(s) for a frame-based protocol. For example, for the HTTP/2 protocol, it is possible that the server starts sending data as soon as the client connects and before a request or other bytes are sent by the client. 
     It will be apparent from this description that aspects of the inventions may be embodied, at least in part, in software. That is, link evaluation module  115 , DNS module  120 , forwarding module  125 , path computation module  130 , and/or computer-implemented method  200  may be implemented or otherwise carried out in a computer system or other data processing system, such as one or more respective nodes  105 , in response to its processor executing sequences of instructions contained in a memory or other non-transitory machine-readable storage medium. The software may further be transmitted or received over a network (not shown) via a network interface. In various embodiments, hardwired circuitry may be used in combination with the software instructions to implement the present embodiments. Thus, the techniques are not limited to any specific combination of hardware circuitry and software, or to any particular source for the instructions executed by a node  105 . It will also be appreciated that additional components, not shown, may also be part of nodes  105 , and, in certain embodiments, fewer components than that shown in  FIG.  1    may also be used in nodes  105 . 
     An article of manufacture may be used to store program code providing at least some of the functionality of the embodiments described above. Additionally, an article of manufacture may be used to store program code created using at least some of the functionality of the embodiments described above. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories—static, dynamic, or other), optical disks, CD-ROMs, DVD-ROMs, EPROMs, EEPROMs, magnetic or optical cards, solid state drives (SSD), or other type of non-transitory computer-readable media suitable for storing electronic instructions. Additionally, embodiments of the invention may be implemented in, but not limited to, hardware or firmware utilizing an FPGA, ASIC, a processor, a computer, or a computer system including a network. Modules and components of hardware or software implementations can be divided or combined without significantly altering embodiments of the invention. 
     In the foregoing specification, the invention(s) have been described with reference to specific exemplary embodiments thereof. Various embodiments and aspects of the invention(s) are described with reference to details discussed in this document, and the accompanying drawings illustrate the various embodiments. The description above and drawings are illustrative of the invention and are not to be construed as limiting the invention. References in the specification to “one embodiment,” “an embodiment,” “an exemplary embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but not every embodiment may necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, such feature, structure, or characteristic may be implemented in connection with other embodiments whether or not explicitly described. Additionally, as used in this document, the term “exemplary” refers to embodiments that serve as simply an example or illustration. The use of exemplary should not be construed as an indication of preferred examples. Blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, dots) are used to illustrate virtualized resources or, in flow charts, optional operations that add additional features to embodiments of the invention. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the invention. Numerous specific details are described to provide a thorough understanding of various embodiments of the present invention. However, in certain instances, well-known or conventional details are not described in order to provide a concise discussion of embodiments of the present inventions. 
     It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. For example, the methods described in this document may be performed with fewer or more features/blocks or the features/blocks may be performed in differing orders. Additionally, the methods described in this document may be repeated or performed in parallel with one another or in parallel with different instances of the same or similar methods.