The present disclosure relates to content delivery networks and to methods and network nodes enabling the content delivery network to handle unexpected surges of traffic.
Content delivery network or content distribution network (CDN) 10, such as the network illustrated in
As a value-added network, CDN 10 is built on top of the internet to improve the round-trip time (RTT) which implies the quality of experience (QoE) when delivering any types of contents to end-users. This delivery is mainly orchestrated by 3 types of entities or functions:
Two main different Request Routing mechanisms are used in CDN, one is hypertext transfer protocol (HTTP) and the other is domain name server (DNS) based. Below are some feature parities between these routing mechanisms:
HTTP-RR is explicit compared to DNS-RR, which is more transparent. Video delivery (live, VOD, etc.) employs HTTP-RR mechanism more often as it is not only richer in term of features but also provides more control and efficiency in content delivery.
Referring to
The latter is a better fit for video on demand (VOD) delivery as it uses the storage efficiently when caching contents. Furthermore, it can also scale smoothly due to nature of the VOD traffic (i.e. low concurrency).
Live video traffic is also suitable for CBRR when there is a smooth increase in audience size, which translates into low initial concurrent delivery and traffic.
Turning to
For a live flash-mob event such as sporting events, e.g. football games, music shows, or some breaking news, the feedback from the monitoring are often too late for scaling up. At instance t1, decisions have already been taken by RRs to route end-users to DN1 which was currently having a low processing load. However, sending such a high number of users at the same time to DN1 can create an instant overload on the node at t2. After being notified by monitoring service of the overload, RRs will of course scale up, and the overloading effect will cascade to the next selected delivery node. However, the experience of end-users who have been assigned to the overloaded DN1, at this point, have already suffered: either by streaming the lowest profile (dropped bit rate) or enduring big latency which would eventually chock up (dropped image quality and possible apparition of visual artifacts) the media players.
The situation described above makes it difficult to use CBRR for live channels during big events, thus making round-robin selection appear to be a more suitable choice. However, round-robin would mean distributing the delivery of the same channel across all DNs of the regional cluster during flash-mob events, hence causing more traffic and sessions on the next hop and origin servers.
There is provided a method, executed in a network node, for providing a traffic prediction for a content for a delivery node in a content delivery network. The method comprises getting an initial state of the delivery node and setting a current state to the initial state, computing the traffic prediction for the content for the delivery node based on the current state and providing the traffic prediction for the content for the delivery node to a second network node.
There is also provided a method, executed in a network node, for handling a request for a content in a content delivery network. The method comprises receiving the request for the content from a client, obtaining a traffic prediction for the content, for at least one of a plurality of delivery node, responsive to obtaining the traffic prediction for the content, selecting a delivery node of the plurality of delivery nodes for serving the content to the client and sending metadata associated to the request to a second network node.
There is provided a traffic analyzer for providing a traffic prediction for a content for a delivery node in a content delivery network comprising processing circuitry and a memory. The memory contains instructions executable by the processing circuitry whereby the traffic analyzer is operative to get an initial state of the delivery node and setting a current state to the initial state, compute the traffic prediction for the content for the delivery node based on the current state and provide the traffic prediction for the content for the delivery node to a second network node.
There is provided a request router for handling a request for a content in a content delivery network comprising processing circuitry and a memory. The memory contains instructions executable by the processing circuitry whereby the request router is operative to receive the request for a content from a client, obtain a traffic prediction for the content, for at least one of a plurality of delivery node, responsive to obtaining the traffic prediction for the content, select a delivery node of the plurality of delivery nodes for serving the content to the client and send metadata associated to the request to a second network node.
There is provided a content delivery network for providing contents to clients and able to handle unexpected surges of traffic. The content delivery network comprises at least one traffic analyzer as described previously and at least one request router as described previously. The at least one request router continuously receives traffic predictions from the at least one traffic analyzer.
Various features and embodiments will now be described with reference to the figures to fully convey the scope of the disclosure to those skilled in the art.
Many aspects will be described in terms of sequences of actions or functions. It should be recognized that in some embodiments, some functions or actions could be performed by specialized circuits, by program instructions being executed by one or more processors, or by a combination of both.
Further, some embodiments can be partially or completely embodied in the form of computer readable carrier or carrier wave containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
In some alternate embodiments, the functions/actions may occur out of the order noted in the sequence of actions or simultaneously. Furthermore, in some illustrations, some blocks, functions or actions may be optional and may or may not be executed; these are generally illustrated with dashed lines.
The solution to the above-mentioned problem illustrated in
Turning to
The real-time nature of the prediction service should compensate for the gap time between KPI collection intervals. A flash mob scenario should be detected the moment it starts, allowing the RR to respond in the most proactive way in order to optimize CBRR for efficient utilization of CDN resources.
The introduction of the traffic load predictive capability in RR should help the RR smoothly handle flash mob events without penalizing the end user streaming experience.
The proposed solution, that will be described in more details further below, should benefit not only the utilization of CDN but also the end user experience in preventing DNs from sudden surges in traffic leading to resource overload and in protecting end users from suffering poor service quality. Further, DNS-RR based traffic, like web content, should also benefit from the cost prediction added to the weighted round robin feature. The solution should also allow eliminate the need for roll back from CBRR to basic Round Robin method, which increases the load on the origin servers.
The RR with predictive routing service will now be described in more details with reference to the example illustrated in
As previously described, RRs 20 today operates in stateless mode. The RR decision-making ability is based-on data gathered from past/ongoing traffic on DNs 70. The solution proposed herein brings the RR 20 from a reactive to a proactive mode by introducing two levels of intelligence: the assistance of machine learning which operates on big data previously gathered; and the tracking of new traffic being redirected to each DN 70. With this, the RR possesses the capability to calculate ongoing traffic, and to predict new traffic load prior to making the decision as to which DN to redirect incoming requests from clients 40.
At initial steps 701 to 715, the request router 20 gets information from different nodes, namely configuration (CFG) 58, geo/policy 52, monitoring KPIs 56, health check 54 and traffic analyzer 30 and register for updates from these network nodes. The configuration data requested and received from the CFG service node 58, steps 701-702, can include CDN topology (network, DNs, IP meshes . . . ) and service offering (live/video-on-demand, HDS/HLS . . . ) configuration, for example. The geo/policy data requested and received from the Geo/Policy node 52, steps 704-705, concerns the client access policies relating to Internet Protocol (IP) geo-locations. The monitoring KPI data requested and received from the Monitoring node 56, steps 707-708, can comprise data such as, central processing unit (CPU), throughput and latency data per DN, for example. The health check data requested and received form the Health check node 54, steps 710-711, relates to the continuous monitoring of the service availability of the DNs (e.g. network connectivity, port reachability, etc.). The traffic data requested and received from the traffic analyzer node 30, steps 713-714, is the traffic shape of an initial snapshot of the predicted traffic when the traffic analyzer starts up. The RR is then ready to handle client requests, step 716.
At steps 717, the configuration is changed in the CFG service 58. The RR is updated at step 718 and the traffic analyzer 30 is updated at step 719. The updated information sent from the CFG node to the RR and to the traffic analyzer 30 can comprise information such as described in relation to table 2 further below. The RR handles the CFG change i.e. updates the configuration information that the RR locally stores at step 720. This kind of updates happen approximately on an hourly basis.
At step 721 the GeoIP is changed. For example, new IP ranges can be added. The RR is updated, step 722, and handles the GeoIP change, e.g. by storing the new IP ranges in a local copy of its memory, step 723. This kind of update happens approximately on a weekly basis.
At step 724, there is a KPI update which is based on the DN traffic handling. The updated information is sent from the monitoring node 56 to the RR 20 at step 725 and to the traffic analyzer 30 at step 726 and can comprise information such as described in relation to table 2 further below. This kind of updates happen approximately on a seconds basis, and can be every several seconds, for example every ten seconds.
At step 727, the DN health check is changed by network conditions of traffic load. The Health check node 54 updates the RR 20 with updated DNs state at step 728. This kind of updates happen approximately on a seconds basis. At step 729, the RR handles the DNs state change. For example, the RR updates the blacklist and whitelist of DNs. Using the blacklist and whitelist, the RR can redirect incoming user requests only to healthy DNs.
The analytics node 60 runs scheduled analytics report, step 730, and updates the traffic analyzer accordingly approximately every minute, step 731. Running the analytics report can comprise measuring the number of requests and transactions per second, by DN, as well as measuring packet size and cache duration (i.e. max-age header value per account offering. The analytics report can be based on information such as described in relation to table 2 further below.
In response to receiving the analytics report, the traffic analyzer (TA) 30 computes a traffic cost per DN based on the traffic served, step 732, and updates the RR 20 with the traffic cost. This kind of updates happen approximately on a milliseconds basis. The RR 20 then handles the traffic cost change, steps 734 to 735. The RR aggregates the predicted traffic load per DN based on the requests, each request having a weight determined based on different dimensions such as CPU, bandwidth and latency requirements, step 735. The RR then evaluates high and low marks, step 736t, i.e. the upper and lower KPI thresholds (bandwidth, CPU . . . ) being used by RR to blacklist and whitelist a DN, i.e. blacklist when exceeding the high mark and whitelist only when it goes below the low mark. This would prevent the jittering effect on the DN. The RR updates the DN blacklist and whitelist that it keeps based on predicted traffic, steps 737 and 738.
At this point, the RR 20 is ready to receive new client requests, step 739. In the example of
At step 742, the RR sends the request data (selected DN, URL, account-offering information) to the traffic analyzer. Account offering may be defined as a service canvas holding the specific feature configurations related to the service level agreement, as an example, a content provider (e.g. Radio-Canada) account for HLS delivery to particular devices, (e.g. iPhone® devices). In response, the traffic analyzer predicts traffic cost based on the model (account-offering metadata) which comprise characteristics of the content of the content provider, step 743 and aggregates cost (such as CPU, bandwidth and latency costs), per DN, based on measured KPI and predicted traffic, step 744.
The RR sends a temporary redirect to the client at step 745, and the client requests to get the media manifest from node DN1 at step 746.
The DN handles the request at steps 747 to 752, where it checks if the manifest is cached locally at step 748, the DN does URL translation (from an external path to an internal path to the CDN) at step 749, the RR sends an HTTP request for the media manifest to the origin server 80 at step 750 and received a response with the manifest at step 752. At step 753, the DN sends the manifest to the client. The client can then start playing the requested content.
To ensure a fast processing speed in the RR 20, the data predicted by TA 30 should be persistent in memory and should be available for instantaneous retrieval. Therefore, in one embodiment, it is proposed to have two TAs 30 operating in tandem. Both TA can register to received update from KPI monitor 56 and Redirected Request Data (see step 742 of
The traffic analyzer interoperation is now explained. The TA can base its traffic prediction on inputs from different components:
Throughout the operation, RRs and TAs will continuously exchange with each other feedback data:
Traffic Update Frequency at the TA update may be calculated as follows:
f
TA=1000/(RRR/RDN)
For the remaining of the document, fTA will be assumed to have a value of 50 msec but of course this value could be different.
The prediction function in TA is based on a formula with a combination of static, dynamic, measured and predicted inputs from four different components at different time intervals as explained previously:
Using inputs such as those enumerated in table 2, the TA can predict the traffic load in the DNs with the following formula:
F
TA
=F
ao(S,D,P)
+F
dn(M,P)
In an example embodiment, the different KPIs could be defined and/or have values such as:
S, Static KPI: AccountOfferingID=123, ContentType=HSS, ServiceType=Live, CachingType=Memory.
D, Dynamic KPI: AccountOfferingID=123, URLparth=/channel1/qualitylevel . . . , SelectedDN=DN1.
P, Predicted KPI: AccountOfferingID=123, SelectedDN=DN1, AvgSize=1612345, TPS=600.
M, Measured KPI: SelectedDN=DN1, CPU=45, Throughput=4123456789, latency=123.
The account offering function could be defined as: ((a/AvgSize)+(b/ContentType)+(c/ServiceType)+(d/CachingType)), where: a+b+c+d=100%.
The delivery node function could be defined as: (CPU/TPS; Throughput/TPS) where CPU-cost=CPU/TPS and Throughput-cost=Throughput/TPS; cost referring to both CPU and Throughput cost.
Of course, in other embodiments, the functions could be defined differently, according to system design and needs, as would be apparent to a person skilled in the art.
Turning to
In the method, getting an initial state of the delivery node may comprise getting configuration, step 903, performance indicators, step 904, and an analytics report, step 905, from a counterpart traffic analyzer; and subscribing to configuration, performance indicators, and analytics report, updates, steps 906-908, from the counterpart traffic analyzer.
In the method, getting an initial state of the delivery node may comprise getting configuration, performance indicators and an analytics report from a configuration node, monitoring node and an analytics node respectively; and subscribing to configuration, performance indicators and analytics report updates, steps 906-908, from the configuration node, monitoring node and analytics node respectively.
Getting an initial state may comprise getting an initial state for a plurality of delivery nodes.
The traffic prediction may be a function of static, dynamic and predicted account offering and of measured and predicted traffic at the delivery node.
In the method, providing the traffic prediction for the content may comprise providing the traffic perdition for the plurality of delivery nodes and the traffic prediction may be provided to a request router, step 911.
The traffic prediction may be provided to a plurality of request routers.
The method may further comprise receiving configuration, performance indicators and analytics report updates, steps 915 and 917, and updating the current state, steps 916 and 918.
The current state may further comprise a traffic status and the method may further comprise receiving a redirected request update from the request router, step 919; and updating the traffic status with information related to the redirected request, step 920.
The performance indicators update may occur approximately every second or it could alternatively happen every ten seconds, step 912 and the analytics report update may occur approximately every five minutes, step 913. The redirected request update may occur continuously, step 914. The traffic status may be stored in a traffic table. Steps 910 to 920 are executed in loop, steps 909 and 921 and may be executed, for example, every 50 milliseconds, step 922.
Turning to
The method may further comprise subscribing to a health check service, subscribing to performance indicators updates and subscribing to traffic prediction updates, steps 1001, 1002 and 1003, for the plurality of delivery nodes.
The method may further comprise receiving and storing performance indicators, steps 1008 and 1009; and updating a black list of delivery nodes as a function of the performance indicators, step 1010.
The method may further comprise receiving services statuses from the health check service, step 1011; and updating a black list of delivery nodes as a function of the services statuses, step 1012.
The method may further comprise, after the step of receiving traffic predictions from a traffic analyzer, step 1013, updating a black list of delivery nodes as a function of the traffic predictions, step 1014.
The network node may be a request router and the second delivery node may be a traffic analyzer. The performance indicators may be received approximately every ten seconds, step 1005. The services statuses may be received approximately every second, step 1006. The traffic predictions may be received continuously, step 1007.
In the method, selecting a delivery node may further comprise access policy validation, step 1016, locating a delivery nodes cluster based on client proximity, step 1017; discarding delivery nodes from the cluster if said delivery nodes are listed in the blacklist of delivery nodes, steps 1019 to 1020; applying a content based request routing algorithm to select a delivery node, step 1021; and redirecting the request from the client to the selected delivery node, step 1023. Steps 1005 to 1024 are executed in loop, step 1004.
Referring to
Still referring to
Although all of the details of the network node are not illustrated, the network node comprises one or several general-purpose or special-purpose processors, or processing circuitry 1100, or other microcontrollers programmed with suitable software programming instructions and/or firmware to carry out some or all of the functionality of the network node described herein. In addition, or alternatively, the network node may comprise various digital hardware blocks (e.g., one or more Application Specific Integrated Circuits (ASICs), one or more off-the-shelf digital or analog hardware components, or a combination thereof) (not illustrated) configured to carry out some or all of the functionality of the network node described herein. A memory 1110, such as a random access memory (RAM), may be used by the processing circuitry 1100 to store data and programming instructions which, when executed by the processing circuitry 1100, implement all or part of the functionality described herein. The network node may also include one or more storage media (not illustrated) for storing data necessary and/or suitable for implementing the functionality described herein, as well as for storing the programming instructions which, when executed on the processing circuitry 1100, implement all or part of the functionality described herein. One embodiment of the present disclosure may be implemented as a computer program product that is stored on a computer-readable storage medium, the computer program product including programming instructions that are configured to cause the processing circuitry 1100 to carry out the steps described herein.
Referring back to
Turning to
In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 1200 hosted by one or more of hardware nodes 1230. Further, in some embodiments the network node may be entirely virtualized.
The functions may be implemented by one or more applications 1220 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement steps of some methods according to some embodiments. Applications 1220 run in virtualization environment 1200 which provides hardware 1230 comprising processing circuitry 1260 and memory 1290. Memory 1290 contains instructions 1295 executable by processing circuitry 1260 whereby application 1220 is operative to provide any of the relevant features, benefits, and/or functions disclosed herein.
Virtualization environment 1200, comprises general-purpose or special-purpose network hardware devices 1230 comprising a set of one or more processors or processing circuitry 1260, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory 1290-1 which may be non-persistent memory for temporarily storing instructions 1295 or software executed by the processing circuitry 1260. Each hardware devices may comprise one or more network interface controllers 1270 (NICs), also known as network interface cards, which include physical network interface 1280. Each hardware devices may also include non-transitory, persistent, machine readable storage media 1290-2 having stored therein software 1295 and/or instruction executable by processing circuitry 1260. Software 1295 may include any type of software including software for instantiating one or more virtualization layers 1250 (also referred to as hypervisors), software to execute virtual machines 1240 as well as software allowing to execute functions described in relation with some embodiments described herein.
Virtual machines 1240, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1250 or hypervisor. Different embodiments of the instance of virtual appliance 1220 may be implemented on one or more of virtual machines 1240, and the implementations may be made in different ways.
During operation, processing circuitry 1260 executes software 1295 to instantiate the hypervisor or virtualization layer 1250, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer 1250 may present a virtual operating platform that appears like networking hardware to virtual machine 1240.
As shown in
Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.
In the context of NFV, a virtual machine 1240 is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of virtual machines 1240, and that part of the hardware 1230 that executes that virtual machine, be it hardware dedicated to that virtual machine and/or hardware shared by that virtual machine with others of the virtual machines 1240, forms a separate virtual network elements (VNE).
Still in the context of NFV, Virtual Network Function (VNF) is responsible for handling specific network functions that run in one or more virtual machines 1240 on top of hardware networking infrastructure 1230 and corresponds to application 1220 in
In some embodiments, one or more radio units 12200 that each include one or more transmitters 12220 and one or more receivers 12210 may be coupled to one or more antennas 12225. Radio units 12200 may communicate directly with hardware nodes 1230 via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station.
In some embodiments, some signaling can be effected with the use of control system 12230 which may alternatively be used for communication between the hardware nodes 1230 and the radio units 12200.
Modifications and other embodiments will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that modifications and other embodiments, such as specific forms other than those of the embodiments described above, are intended to be included within the scope of this disclosure. The described embodiments are merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, rather than the preceding description, and all variations and equivalents that fall within the range of the claims are intended to be embraced therein. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/IB2017/053671 | 6/20/2017 | WO | 00 |