Traffic shaping based on predicted network resources

In one embodiment, a committed information rate (CIR) prediction is received from a machine learning model that corresponds to a predicted average traffic rate supported by a network connection. A traffic shaping strategy is adjusted based on the CIR prediction. A rate at which data is communicated over the network connection may be based on the traffic shaping policy. The effects of the adjusted traffic shaping strategy are also monitored. Feedback is further provided to the machine learning model based on the monitored effects of the adjusted traffic shaping strategy.

TECHNICAL FIELD

The present disclosure relates generally to computer networks, and, more particularly, to using predicted network resources to perform traffic shaping.

BACKGROUND

Enterprise networks are carrying a very fast growing volume of both business and non-business critical traffics. Often, business applications such as video collaboration, cloud applications, etc., use the same hypertext transfer protocol (HTTP) and/or HTTP secure (HTTPS) techniques that are used by non-business critical web traffic. This complicates the task of optimizing network performance for specific applications, as many applications use the same protocols, thus making it difficult to distinguish and select traffic flows for optimization.

As the number of business and non-business critical applications increases, so too are the number and variety of service level agreements (SLAs) that may be in use by a network. In general, an SLA refers to a target or threshold level of performance guaranteed by the network, and may be associated with a particular type of traffic. For example, many real-time business applications are very bandwidth demanding and have corresponding SLAs that are used to ensure that a certain amount of network bandwidth is available for a particular flow of traffic.

Traditionally, reactive techniques have been used to enforce network performance criteria, such as SLAs. First, the network itself is engineered by defining the application SLAs, quality of service (QoS) parameters, security settings, etc. Next, the performance criteria are monitored in view of the network's performance. If the performance criteria are not met, adjustments may then be made to the network in a reactive manner. However, such a reactive approach may also, by its very nature, mean that the network experiences periods of reduced performance before corrective measures are taken.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

According to one or more embodiments of the disclosure, a committed information rate (CIR) prediction is received from a machine learning model that corresponds to a predicted average traffic rate supported by a network connection. A traffic shaping strategy is adjusted based on the CIR prediction. A rate at which data is communicated over the network connection may be based on the traffic shaping policy. The effects of the adjusted traffic shaping strategy are also monitored. Feedback is further provided to the machine learning model based on the monitored effects of the adjusted traffic shaping strategy.

Description

2.) Site Type B: a site connected to the network using two MPLS VPN links (e.g., from different Service Providers), with potentially a backup link (e.g., a 3G/4G/LTE connection). A site of type B may itself be of different types:

2a.) Site Type B1: a site connected to the network using two MPLS VPN links (e.g., from different Service Providers), with potentially a backup link (e.g., a 3G/4G/LTE connection).

2c.) Site Type B3: a site connected to the network using two links connected to the public Internet, with potential a backup link (e.g., a 3G/4G/LTE connection).

Notably, MPLS VPN links are usually tied to a committed SLA, whereas Internet links may either have no SLA at all or a loose SLA (e.g., a “Gold Package” Internet service connection that guarantees a certain level of performance to a customer site).

As will be appreciated, the above topologies are illustrative only and the techniques herein may be used in any other form of computer network. For example, the techniques herein may be adapted for use in a mesh network, such as an Internet of Things network. Loosely, the term “Internet of Things” or “IoT” refers to uniquely identifiable objects (things) and their virtual representations in a network-based architecture. In particular, the next frontier in the evolution of the Internet is the ability to connect more than just computers and communications devices, but rather the ability to connect “objects” in general, such as lights, appliances, vehicles, HVAC (heating, ventilating, and air-conditioning), windows and window shades and blinds, doors, locks, etc. The “Internet of Things” thus generally refers to the interconnection of objects (e.g., smart objects), such as sensors and actuators, over a computer network (e.g., IP), which may be the public Internet or a private network.

FIG. 2is a schematic block diagram of an example node/device200that may be used with one or more embodiments described herein, e.g., as any of the routers as shown inFIG. 1, particularly the PEs120, CEs110, a network controller (e.g., a device associated with a network operations center (NOC)), or any other computing device that supports the operations of network100(e.g., switches, etc.). Device200comprises a plurality of network interfaces210, one or more processors220, and a memory240interconnected by a system bus250and powered by a power supply260. The network interfaces210contain the mechanical, electrical, and signaling circuitry for communicating data over physical links coupled to the network100. The network interfaces may be configured to transmit and/or receive data using a variety of different communication protocols. Notably, a physical network interface210may also be used to implement one or more virtual network interfaces, such as for virtual private network (VPN) access, known to those skilled in the art.

The memory240comprises a plurality of storage locations that are addressable by the processor(s)220and the network interfaces210for storing software programs and data structures associated with the embodiments described herein. The processor220may comprise necessary elements or logic adapted to execute the software programs and manipulate the data structures245. An operating system242(e.g., the Internetworking Operating System, or IOS®, of Cisco Systems, Inc., another operating system, etc.), portions of which are typically resident in memory240and executed by the processor(s), functionally organizes the node by, inter alia, invoking network operations in support of software processes and/or services executing on the device. These software processes and/or services may comprise routing process244(e.g., routing services) and illustratively, a network analyzer module (NAM)246, a predictive control manager (PCM)247, a traffic pattern analyzer (TPA)248, and/or a traffic shaping module249, as described herein, any of which may alternatively be located within individual network interfaces.

Routing process/services244contain computer executable instructions executed by processor220to perform functions provided by one or more routing protocols, such as the Interior Gateway Protocol (IGP) (e.g., Open Shortest Path First, “OSPF,” and Intermediate-System-to-Intermediate-System, “IS-IS”), the Border Gateway Protocol (BGP), etc., as will be understood by those skilled in the art. These functions may be configured to manage a forwarding information database containing, e.g., data used to make forwarding decisions. In particular, changes in the network topology may be communicated among routers200using routing protocols, such as the conventional OSPF and IS-IS link-state protocols (e.g., to “converge” to an identical view of the network topology).

Notably, routing process244may also perform functions related to virtual routing protocols, such as maintaining VRF instances, or tunneling protocols, such as for MPLS, generalized MPLS (GMPLS), etc., each as will be understood by those skilled in the art. Also, EVPN, e.g., as described in the IETF Internet Draft entitled “BGP MPLS Based Ethernet VPN” <draft-ietf-12vpn-evpn>, introduces a solution for multipoint L2VPN services, with advanced multi-homing capabilities, using BGP for distributing customer/client media access control (MAC) address reach-ability information over the core MPLS/IP network.

In some implementations, routing services244may include a distributed application policy infrastructure controller (dAPIC) that operates to enforce application-specific policies on the local device. For example, the dAPIC may receive application-specific SLAs from a network controller via application programming interface (API) calls. Such information may be used, in some cases, to make routing decisions based on the type and priority of an application, as well as the performance of the various network links available to the device. In other words, the dAPIC in routing services244may be part of an application centric infrastructure (ACI) that operates to centralize network automation and facilitate the use of policy-driven application profiles throughout the network.

As noted above, traffic and network characteristics may be highly dynamic, making WAN optimization challenging. In addition, the variety of access links that may be involved (e.g., cable, A/V/DSL, links over private or public networks, etc.), potentially with guaranteed SLAs or semi-guaranteed SLAs, further complicates the task of network optimization. In some cases, customer sites may also be connected to backup links (e.g., 3G/4G/LTE wireless links) that provide highly varying performances in terms of connectivity and bandwidth.

According to various embodiments described herein, a dynamic, predictive performance architecture is disclosed that may be implemented in a network, such as a multi-service, multi-carrier WAN. In particular, NAM246, PCM247, TPA248, and/or traffic shaping module249may operate in conjunction to perform predictive networking, in contrast with existing approaches that rely on reactive networking techniques. In some aspects, TPA248may be responsible for tracking all possible attributes of the traffic that is flowing through a router or other device, in order to make predictions regarding the traffic. For example, these attributes may be used to characterize traffic flows over the course of time and to generate profiles that can be used for prediction. In another aspect, NAM246may be used to generate an analytical model of the attributes of the network (potentially as a function of time), in order to predict network performance. In a further aspect, PCM247may gather application-specific SLAs (e.g., from the ACI controller/dAPIC of routing services244) and correlate the application-specific SLAs with the predicted traffic profile and network performance, to perform closed-loop control that meets the application-specific SLAs. Traffic shaping module249may operate to determine network characteristics, such as those used by NAM246. In various implementations, processes244and246-249may be co-located or may be distributed across different network devices. Further, while certain functions are described herein with respect to a particular one of processes244,246-249, the functions may be incorporated into any of the other processes, in various other embodiments.

Numerous types of application traffic may be flowing through current day networks. For example, as shown inFIG. 3, a particular CE110located at a customer site may provide and receive different forms of application traffic that is communicated through network100. For example, traffic associated with a given customer site may include, but is not limited to, video data (e.g., video conferencing data), audio data (e.g., voice-over-IP (VoIP)), enterprise resource planning (ERP) data, customer relationship management (CRM) data, and the like. Each form of traffic may have specific network requirements and may be very demanding with respect to network availability and resiliency, such that even small deviations in network conditions may render an application incapable of providing the requisite experience to the end user. For example, low network performance may result in a video conference appearing choppy to the end users.

According to various embodiments, a predictive performance methodology for WANs and other forms of networks is introduced that that allows for its use across varying network architectures, application requirements, and deployment strategies, as well as in the presence of dynamic traffic and network performances. As detailed below, such an architecture may make use of machine learning techniques, in some embodiments, to evaluate future network requirements and performance, and to take corrective measures within the network to ensure the SLAs are met.

Referring now toFIGS. 4A and 4B, an example architecture400for predictive networking is shown in greater detail, according to various embodiments. As shown inFIG. 4A, TPA248, NAM246, and/or a dAPIC410may be local or remote to a given device200. InFIG. 4B, PCM247may be hosted on a different device, such as a network controller, or may be integrated into the same device as that illustrated inFIG. 4A, in various embodiments.

Learning machines (e.g., learning machines402-406) are computational entities that rely on one or more machine learning processes for performing a task for which they have not been explicitly programmed to perform. In particular, learning machines are capable of adjusting their behavior to their environment. For example, a learning machine may dynamically make future predictions based on current or prior network measurements, may make control decisions based on the effects of prior control commands, etc.

Learning machines402-406may employ any number of different machine learning techniques. For example, artificial neural networks (ANNs) are a type of machine learning technique whose underlying mathematical models were developed inspired by the hypothesis that mental activity consists primarily of electrochemical activity between interconnected neurons. ANNs are sets of computational units (neurons) connected by directed weighted links. By combining the operations performed by neurons and the weights applied by the links, ANNs are able to perform highly non-linear operations to input data. The interesting aspect of ANNs, though, is not that they can produce highly non-linear outputs of the input, but that they can learn to reproduce a predefined behavior through a training process. Other forms of machine learning techniques that may be employed by learning machines402-406may include, but are not limited to, support vector machines (SVMs), Bayesian networks, regression techniques (e.g., logistic regression, linear regression, non-linear regression, etc.), combinations thereof, or any other form of machine learning.

In various embodiments, TPA248may reside within a router or on a host computing device, and may have connectivity to one or multiple routers in the network. In general, TPA248may be operable to analyze every facet of the traffic flowing through the router. For example, TPA248may receive traffic-related data from the operating system of the device via an OS configuration translator434, such as from an application visibility and control (AVC) process that is configured to classify traffic data according to application type (e.g., Cisco AVC® of Cisco Systems, Inc.), a network traffic flow process (e.g., Cisco IOS Flexible Netflow® of Cisco Systems, Inc.), a media metrics process (e.g., a process that generates metrics regarding video streams), etc. These or other such reporting technologies may be used by TPA248to compute a set of input feature data436(e.g., attributes that capture the characteristics of the traffic), that may be used by learning machine402to predict a traffic profile.

Feature data436may include any or all of the following information:

1.) Bandwidth Usage Data438: In some cases, feature data436may include data regarding the bandwidth usage of a particular type of traffic (e.g., application-specific bandwidth usage information). This information may provide a profile of the traffic over the course of time to learning machine402.

2.) Application Type Data440: Feature data436may include data regarding the various application types associated with the traffic (e.g., VoIP, video, etc.). In various embodiments, application types may be determined based on the port numbers used, via an application recognition utility (e.g., Network Based Application Recognition® of Cisco Systems, Inc.), or the like.

3.) Flow Characteristics442: In some cases, feature data436may include traffic flow information such as the duration of a flow, the rate of new flows, metrics capturing the rate of change of the previous metrics over time, or other such information. These flow characteristics may be captured from underlying infrastructures such as an application recognition utility, a call manager, or the like.

4.) Statistical Measurements444: In some embodiments, feature data436may include statistical measurements regarding the flow of traffic. For example, measurements444may include data regarding the moments (e.g., variance, skewness, kurtosis, etc.) of the traffic distribution, both in terms of packets/sec and bytes/sec, on a per flow basis, or on a per time path basis. In another example, measurements444may include other statistical properties of the traffic flow, such as autocorrelation, Fourier series coefficients, etc.

Together, feature data436can be used by learning machine402to determine characteristics of the underlying traffic flow and how it changes with time. Once learning machine402starts to develop a time series model using these attributes, for example, it may decide that it needs more information about some of these features or, conversely, that some of these features are not relevant. In such cases, the update rate of the features may be adjusted accordingly by TPA248(e.g., to reduce the update rate of irrelevant data, etc.). In one embodiment, adjusting the refresh rate of feature data436may be policy-based to reduce traffic overhead in the network. For example, certain features may be collected or refreshed at different rates depending on the time of day, to reduce adverse effects on the network from the collection.

In some implementations, TPA248may require some processing capabilities that are not available on the router carrying the actual traffic itself. In such cases, TPA248may be hosted on a different router/host, which may be co-located either on a router blade (e.g., a UCS blade), or a different router/host connected to the router via a high bandwidth link.

According to various embodiments, NAM246may reside on the router processing the traffic under analysis itself or on a host that has network connectivity to the concerned routers. In general, NAM246may be operable to track all the network conditions that are visible to the corresponding router, in order to model the network performance characteristics. In contrast with reactive approaches, NAM246may be used to compute a model of the network performance using learning machine404. For example, NAM246may determine the performance of each link/path available to connect a remote/branch office to a corporate network or headquarters.

Similar to TPA248, NAM246may gather feature data450that is used as inputs to learning machine404(e.g., via OS configuration translator446). For example, feature data450may be determined in part by sending probes between a given sender and a given responder, to capture metrics regarding the performance along the path. Other sources of feature data450may also include any or all of the sources used to determine feature data436. In various embodiments, feature data450may include any or all of the following information:

1.) Delay Information452: In some cases, feature data450includes delay measurements along a given network path and/or link.

2.) Bandwidth Information454: Feature data450may also include bandwidth information associated with a given network path and/or link. For example, bandwidth information454may include data regarding the total bandwidth usage of the path or link, the per-application bandwidth usage of the path or link, available bandwidth along the path or link, etc.

3.) Jitter Information456: Feature data450may further include jitter information associated with a given path and/or link. For example, the total amount or application-specific jitter measurements along a path or link may be included in feature data450.

4.) Packet Loss Information458: In some cases, feature data450may include packet loss information, such as a measured packet loss rate along a given path and/or link.

5.) Routing Information460: Associated with any of data452-458may be information regarding a given network path (e.g., the link or set of links for which the measurements of data452-458were determined).

Learning machine404may continually track feature data450(e.g., as a time series model), to characterize these attributes. In other words, learning machine404may use a predictive model to predict future network performance metrics based on feature data450. In some implementations, NAM246may also adjust the collection of feature data450. For example, NAM246may configure one or more corresponding routers to generate more or less features based on the requirements of learning machine404(e.g., the amount of probing used may be adjusted as a function of the model's accuracy and confidence, based on network considerations such as current or future network usage, etc.).

In some embodiments, learning machine404may use the principle of data fusion to model the network performance metrics. This principle generally functions by integrating multiple data sources and knowledge about a real-world process (in this case, the underlying network), into an accurate representation of the functioning of the network. For example, bandwidth data454along a given path may be available from any of the following sources: (1) SLA processes may yield data about the delay, jitter and packet loss, which can, in some circumstances, be used to estimate the available bandwidth via a regression model, such as variational Bayesian least squares (VBLS) regression model, (2) actual bandwidth measurements can be taken occasionally, but with care as they affect the network performance, or (3) time-series models such as autoregressive moving average (ARMA) models, Hidden Markov Models, Gaussian Processes can be used to predict the performance evolution.

Feature data450available from various sources of information can be fused by NAM246in real time in a mathematically principled way by using a Kalman filter or graphical models, whereby the intrinsic uncertainty of each source of information is accounted for in the estimation of the data (e.g., available bandwidth, etc.). For example, if one makes a direct measurement of the actual bandwidth at time t, the uncertainty on this measure is very small, and it should therefore have a very strong impact on the estimation process at time t. However, as t increases, the uncertainty also increases as the actual bandwidth may drift away from the initial measurement. This drift may then be captured via a time-series model, and complemented by indirect measurements (e.g., based on delay, jitter, etc. measurements). As long as both sources agree, there is no reason to perform any further direct measurement, which may be very expensive, but if the prediction of the time-series model and the regression diverges, this may trigger another direct measurement. In some embodiments, NAM246may determine whether a direct measurement of any of feature data450is needed based on a measure of confidence associated with a model used by learning machine404.

In some implementations, dAPIC410may store and provide various application-specific data via a communicator component466. In general, dAPIC410may be operable to ensure that all the application SLAs are being met at all times in the network and, consequently, perform various actions without human intervention, to dynamically adapt the network behavior as needed. Accordingly, dAPIC410may have access to various application-specific SLA information such as SLA data460(e.g., a set of SLAs), duration data462regarding the SLAs (e.g., when a particular SLA is to be enforced), and/or source-destination data464regarding the network paths used by the various applications.

In various embodiments, TPA248, NAM246, and dAPIC410may provide data to PCM247shown inFIG. 4B, which may be co-located with these modules or may be hosted on another device (e.g., in a network controller, in the cloud, etc.). Accordingly, PCM247may include communicator modules412,414, and416to communicate with TPA248, NAM246, and dAPIC410, respectively. In one embodiment, PCM247receives traffic model data generated by learning machine402from TPA248via communicator module412. In a further embodiment, PCM247receives network performance model data generated by learning machine404from NAM246via communicator module414. In yet another embodiment, PCM247may receive application-specific SLA data from dAPIC410(e.g., data460-464), which may have information about all of the applications in the network, as well as their corresponding SLA requirements.

If an application SLA is predicted not to be met, PCM247may take any number of corrective measures to ensure that the SLAs continue to be met (e.g., by sending commands to OS242via an OS translator module432). In some implementations, the corrective measures may be performed via a closed loop controller408, thereby allowing feedback (e.g., updated predictions from TPA248and NAM246) to be used by PCM247when taking corrective measures. In one embodiment, PCM247may generate and send a notification418to a network management system (NMS), allowing a human operator to intervene, if necessary, at the appropriate place and time in the network.

In another embodiment, PCM247may dynamically generate new QoS parameters420such that application-specific SLAs continue to be met. Example QoS parameters may include differentiated services code point (DSCP) parameters421, queue length parameters422, further parameters that change bandwidth percentage allocations to different classes, parameters that change the class of service for applications, etc.

In a further embodiment, PCM247may change call-admission control (CAC) policies424used as part of a communications management system. For example, CAC policies424may include parameters425for a call manager system (e.g., a system that tracks and manages active VoIP network components), drop policy parameters426, or the like. Such parameters may be used, in some cases, to prevent admission of new traffic flows if the available bandwidth is already fully used.

In another embodiment, PCM247may generate path selection parameters428. In general, path selection parameters428may operate to ensure that, based on a particular application type, the corresponding traffic is routed over different paths such that all applications continue to meet their SLAs. For example, path selection parameters428may include one or more static routes429to be used by a particular type of application traffic, path cost values430used to make routing decisions, or any other data that may be used to adjust which paths are used in the network by a particular type of application traffic. For example, traffic of class X may suddenly have to be routed over a 3G/4G link (although more costly) for a period of time T in order to meet the required SLA received from dAPIC410(e.g., application-specific SLAs460), according to the predicted traffic from the TPA248and expected network characteristics from NAM247.

Notably, such a predictive architecture400supports different modes of operation. In some cases, the system may request human intervention as part of the control loop. In other words, PCM247may operate as a distributed recommendation system for network parameter changes that should be adjusted in order to meet the SLAs (e.g., by sending NMS notifications418for review by a network engineer). In other cases, the system may be fully autonomous by employing closed loop control to make decisions on a router in real-time and report on the decisions to a human operator afterwards. As will be appreciated, the various modules described in architecture400may also communicate using remote procedure calls (RPCs) (e.g., using the Apache Thrift® protocol from the Apache Software Foundation or another RPC protocol), allowing the depicted modules to be co-hosted by a device or located remotely on different devices. Communications with the operating system of the device may also be performed using any suitable technique, such as by sending scripts through a Tcl/Shell.

Referring again toFIG. 3, traffic shaping may be performed by a CE router110, to control the rate at which packets are communicated over a network connection with a PE router120(e.g., over an MPLS VPN link, over a public Internet connection, etc.). Traffic shaping may be employed using any number of different link access types (e.g., Frame Relay, ATM, Serial, etc.), in order to control the rate at which packets are communicated (e.g., over an interface, (GRE) tunnel, ATM VC, Frame Relay circuit, etc.).

In contrast with traffic policing whereby traffic exceeding a committed rate is simply discarded, traffic shaping allows traffic rates to be managed via queuing, to comply with a service agreement from a network provider. For example, a Service Provider could provide a T1 physical link with a video conferencing (VC) data rate of X Kbits/s, with X<<T1's bandwidth.

Generic Traffic Shaping (GTS) may rely on the use of one or more token buckets, which are characterized by a Committed Information Rate (CIR). In general, a CIR is a network parameter related to the data rate at which traffic can be transmitted, a Burst Size (Bc), which indicates the number of bits or bytes that can be transmitted per unit of time to avoid queuing, and a Time Interval (TI), which is the time quantum per burst. In other words, communication tokens may be replenished with tokens at a given rate within a router (e.g., CE router110), to allow for a burst of traffic before queuing takes place. Thus, the interface transmission rate will never exceed the mean rate during a given time interval, and a maximum burst size can still be sent during the interval. Notably, the instantaneous bit rate may be higher at any given time during a time interval. GTS may also be extended with an additional token bucket (leading to dual or multiple token buckets) characterized by an Excess Burst Size (Be). Be may be used to avoid tail drop and congestion, which is of the utmost importance with TCP-based traffic, for example.

Said differently, a CIR may be a configurable parameter on a router (e.g., a CE router110) that represents the average traffic rate that may be communicated over a network connection (e.g., by a permanent virtual circuit, etc.) over a given time interval. The CIR is often set much lower than the access rate, which is the speed associated with the physical connection. Typically, a CIR may be determined by a service provider based on statistical multiplexing. However, many networks may experience dramatic variations in the actual available data rates, making it difficult to determine the actual CIR.

In some implementations, traffic shaping may be performed via a statically configured output rate set on a CE router. The traffic shaping function (e.g., traffic shaping module249) then operates to control bursts such that the output rate is smoothed across multiple time periods. Typically, the output rate is set to the CIR, in an attempt to smooth bursts such that the CIR is met. However, if the output rate is less than the true CIR, this may lead to unnecessary queuing and, consequently, delays. Conversely, if the output rate exceeds the true CIR, this may lead to packet drops in the network, with consequences on both TCP-based traffic (e.g., over-reacting to loss) and UDP-based traffic (e.g., application based retransmission).

Traffic Shaping Based on Predicted Network Resources

The techniques herein allow traffic shaping performed by a device to be adjusted dynamically according to predictions made regarding available resources in the network. In various implementations, the predictions may be received by the device in response to sending an explicit request for a prediction (e.g., in response to detecting queuing delays or packet drops) or via unsolicited notifications. In some aspects, the effects of the new traffic shaping strategy may be monitored and feedback may be provided by the device to a network analytics module, to further improve resource predictions. In some aspects, the device may also take temporary corrective measures when queuing delays are detected or when packets are dropped, by using a traffic shaping strategy that differs from the predicted resources.

Specifically, according to one or more embodiments of the disclosure as described in detail below, a committed information rate (CIR) prediction is received from a machine learning model that corresponds to a predicted average traffic rate supported by a network connection. A traffic shaping strategy is adjusted based on the CIR prediction. A rate at which data is communicated over the network connection may be based on the traffic shaping policy. The effects of the adjusted traffic shaping strategy are also monitored. Feedback is further provided to the machine learning model based on the monitored effects of the adjusted traffic shaping strategy.

Illustratively, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with processes244,246-249, which may contain computer executable instructions executed by the processor220(or independent processor of interfaces210) to perform functions relating to the techniques described herein. For example, the techniques herein may be treated as extensions to conventional protocols, such as the various networking protocols or wireless communication protocols, and as such, may be processed by similar components understood in the art that execute those protocols, accordingly.

Operationally, traffic shaping module249may be adapted to operate in conjunction with the predictive networking architecture400shown inFIGS. 4A-4B. In particular, learning machine404in NAM246may predict available network resources, such as available bandwidth for a given network connection. In turn, traffic shaping module249may use these predictions to continually adjust its traffic shaping rate (e.g., its traffic output rate). As noted previously, NAM246and traffic shaping module249may or may not be co-located. For example, traffic shaping module249may be located on a CE router while NAM246is located on another network device, such as a PE router or network controller. In some embodiments, IPv4 or IPv6 unicast messages may be sent between CE router hosting traffic shaping module249and the device hosting NAM246, to facilitate the functions described herein.

For purposes of illustration, let CIR Static (CIR-S) refer to the static CIR set on a given router. CIR-S may be configured locally or, alternatively, be uploaded to the router via an automatic configuration mechanism. In addition, let CIR Predicted (CIR-P) refer to a predicted CIR determined by NAM246. In contrast to implementations in which CIR-S is used to make traffic shaping decisions, the techniques herein may allow the theoretical CIR-S to be compared against fluctuations in CIR-P, for purposes of performance analysis.

In some embodiments, NAM246may send predictions to traffic shaping module249in an unsolicited manner. For example, as shown inFIG. 5A, NAM246may send a predicted CIR (CIR-P)502to traffic shaping module249in response to a change in the value of CIR-P502. In one embodiment, NAM246may send an updated CIR-P502to traffic shaping module249each time the absolute value of CIR-P502changes. In another embodiment, other triggering conditions may be used (e.g., if the percentage of change between current and newly computed values exceeds some threshold, when the absolute change in value is greater than a given value, etc.).

CIR-P502may be determined by NAM246in any number of different ways, depending on the learning machine techniques used by NAM246. For example, assume that NAM246computes a time-based predictive model for the network resource for a given period of time (e.g., the available bandwidth for the next n-number of hours). If the predicted available bandwidth for the time period has increased over the previous time period, NAM246may predict a corresponding increase in CIR-P. Similarly, if the predicted available bandwidth is lower for the time period in comparison to the previous time period, NAM246may predict a corresponding decrease in CIR-P. In other words, CIR-P502may be associated with a particular time period. After expiration of the time period, NAM246may compute a new CIR-P value and provide the value to traffic shaping module249.

In other embodiments, traffic shaping module249may explicitly request a CIR-P value from NAM246. For example, as shown inFIG. 5B, traffic shaping module249may send a prediction request504(e.g., a unicast IP message) to NAM246. In response, NAM246may provide the most current CIR-P value to traffic shaping module249in CIR-P502.

In a first case, traffic shaping module249may send prediction request504to NAM246in response to detecting the presence of local queuing delays. In particular, the traffic shaping module249may be operable to determine whether excessive delays are present due to the use of local queuing. In one embodiment, the router may send probes out that are also subject to the same queuing policies as the current traffic, to determine whether queuing delays are present or excessive (e.g., above a threshold amount). If such delays are present or excessive, traffic shaping module249may send prediction request504to NAM246in the hope that the predicted bandwidth has increased since the last update to CIR-P.

In another embodiment, traffic shaping module249may probe for queuing delays in accordance with traffic predictions from TPA248. Such predictions may be used, for example, to avoid impacting user traffic during the probing process. The additional probing traffic may be destined to a remote CE and should explicitly be acknowledged. For example, in the following topology CE1 - - - PE1 - - - Core PE2 - - - CE2, the traffic shaping module249hosted on CE1 may send additional traffic to CE2 that, in turn, acknowledges the additional traffic.

In a second case, traffic shaping module249may be operable to determine the rate at which packets are dropped (e.g., such as with TCP-based traffic). When these metrics are available and the amount or rate of dropped packets exceeds a threshold value, traffic shaping module249may send prediction request504to NAM246for an updated prediction. In some embodiments, traffic shaping module249may also temporarily override the prediction, in order to reduce to request the shaper to reduce the rate of shaping, waiting for further updates from NAM246. In another embodiment, traffic shaping module249may continue to monitor the packet drop rates to ensure that reducing the traffic had an impact on the packet drops. In other words, reducing the traffic rate may not have an effect if packets are dropped for other reasons such as lossy links (e.g., in the case of IoT networks), as opposed to the router simply having too high of an output rate.

As shown inFIG. 5C, traffic shaping module249may use CIR-P502from NAM246to make traffic shaping decisions. For example, traffic shaping module249may increase or decrease its traffic shaping output rate based on a corresponding increase or decrease in value of CIR-P502. Notably, in the case in which queuing delays are present, an increase in CIR-P (if predicted) may result in a reduction in queuing delays. Said differently, the amount of queuing may be reduced if the network is predicted to support a higher traffic rate. Conversely, in the case in which packet drops are detected, a decrease in CIR-P (if predicted) may result in fewer packet drops, assuming the dropped packets are attributable to the output traffic rate being too high. As noted above, traffic shaping module249may also adjust its traffic shaping strategy in response to detecting queuing delays or dropped packets, while awaiting an updated CIR-P.

In some embodiments, feedback may be provided by traffic shaping module249to NAM246, thereby forming a feedback control loop. For example, as shown inFIG. 6, traffic shaping module249may send error feedback602to NAM246. Feedback602may indicate, for example, that queuing delays or dropped packets were detected by traffic shaping module249. If feedback602indicates that queuing delays were detected, this may mean that the prediction was too low/conservative. In some cases, feedback602may further indicate that traffic shaping module249has independently confirmed that the prediction was too low via probing. If feedback602indicates that packet drops were detected, this may mean that the prediction was too high/optimistic.

In response to receiving feedback602, NAM246may use feedback602to generate a new CIR-P value and/or adjust its predictive model. For example, NAM246may send an updated CIR-P value604to traffic shaping module249, thereby completing the control loop. Such a feedback mechanism may be employed in either the explicit or solicited cases discussed with respect toFIGS. 5A-5B(e.g., traffic shaping module249may still send feedback602to NAM246, even if the CIR-P values are sent to traffic shaping module249are unsolicited).

Traffic shaping module249and/or NAM246may also provide reporting on the generated CIR-P values. For example, a device hosting either such module may report the set of CIR-P values to a network management system (NMS) for review by a network engineer. In one embodiment, if a CIR-C value is available to the reporting device, the device may only report a CIR-P if the two values differ, as described above. In the absence of a CIP-C value, the device may still optionally send reports indicating the CIR-P values, along with other user traffic metrics (e.g., the detected delay, prediction errors when predictions were too optimistic or pessimistic, etc.).

FIG. 7illustrates an example simplified procedure for performing traffic shaping using predicted network resources in accordance with one or more embodiments described herein. The procedure700may start at step705, and continues to step710, where, as described in greater detail above, a committed information rate (CIR) prediction is received. Such a CIR prediction may correspond to a predicted average traffic rate supported by a network connection for a given period of time. For example, a CIR may be an average bandwidth guaranteed to a virtual circuit or Internet connection by a service provider. As noted above, a CIR prediction may be generated by a learning machine model by making predictions about the available bandwidth within the network.

In step715, a traffic shaping strategy used by a router is adjusted based on the received CIR prediction, as described in greater detail above. In general, the traffic shaping strategy of a router may operate to control the data output rate of the router such that traffic bursts are smoothed out over time in accordance with the controlled output rate. In various embodiments, the output rate of the traffic shaping strategy may be controlled based on the CIR prediction. For example, the output traffic rate may be increased if the CIR prediction indicates a predicted increase in the available bandwidth. Similarly, the output traffic rate may be adjusted downward if the CIR prediction indicates a predicted decrease in the available bandwidth.

At step720, the effects of the adjustment to the traffic shaping strategy are monitored, as highlighted above. In one embodiment, the network may be monitored to determine whether the adjustment to the traffic shaping strategy has resulted in an increase in delays due to local queuing. In some cases, probing packets may also be sent, to confirm whether the delays are attributable to the CIR prediction being too conservative (e.g., whether additional bandwidth is actually available). In another embodiment, the network may be monitored to determine whether the adjustment to the traffic shaping strategy has resulted in an increase in the number or rate of dropped packets. Such an increase may indicate that the CIR prediction was too optimistic and that less bandwidth is actually available.

At step725, feedback may be provided to the machine learning model that generated the CIR prediction, as described in greater detail above. The feedback may be based on the monitored effects of the adjusted traffic shaping strategy. For example, the traffic shaping device may indicate to the machine learning model that the CIR prediction was potentially too high, thereby leading to an increase in dropped packets. In another example, the traffic shaping device may indicate to the machine learning model that the CIR prediction was potentially too low, thereby leading to unnecessary queuing delays. Procedure700then ends at step730.

The techniques described herein, therefore, provide for predictive traffic shaping that allows a router to dynamically adjust its traffic shaping strategy according to the predicted available bandwidth in the network. Notably, if less bandwidth is predicted to be available, the traffic rate may be adjusted downward, thereby avoiding packet drops. Conversely, if more bandwidth is predicted to be available, the traffic rate may be adjusted upward, thereby avoiding delays due to queuing.

While there have been shown and described illustrative embodiments that provide for predictive network control to be used in multicarrier WANs, it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the embodiments herein. For example, the predictive networking techniques described herein may be adapted for use in other forms of networks, such as the IoT. In addition, the embodiments have been shown and described herein with relation to specific protocols and naming conventions for purposes of illustration. However, the embodiments in their broader sense are not as limited, and may, in fact, be used with other types of suitable protocols and/or naming conventions.