May 22, 2019
OTT Content Delivery– Multi CDN
Background
While CDNs are just becoming a commodity for larger websites in the e-commerce, banking, and public sectors, they have been so for long in the media delivery industry. With the unmatched traffic load requirements of media content delivery, the CDNs are pushed to the limit. And when the CDN you use is pushed to its limits, where do you offload your traffic to? Another CDN of course.
This is the second CDN article focusing on Multi CDN technologies. The previous article describes what CDNs are and how they work.
This publication is a part of a series of articles describing the principles of the technology behind video streaming. It could be read without any prior knowledge on the subject.
Why Multi-CDN?
While many CDNs are quickly growing, so is the OTT traffic. Both peak traffic levels but also the base traffic flow. There are two main reasons for this: more viewers and higher bitrates.
Consumers are abandoning their old TV package services distributed via terrestrial, cable, or satellite and turning to OTT services distributed over the HTTP based CDN networks. This is commonly referred to as Cord Cutting (leaving terrestrial) or Cord Switching (cable to IP). And the higher bitrate factor comes from a demand for better quality. Viewing the content on larger screens, video consumers require quality levels reaching HD, and soon also UHD, 4K, and HDR, which all require lots of bandwidth.
Statistics from Statista.com (collected from Cisco) is just one of many showing the aggressive growth of online video streaming. There are many diagrams showing the same growing trend.
A multi-CDN solution enables pushing traffic to multiple CDNs. In its most simple form, the CDNs may be used in a primary-secondary mode where if your primary CDN fails, you can failover all your traffic to the secondary CDN. But when using multiple CDNs, usually each of them runs in parallel to keep the caches “warm” — up to date with the most relevant content. Switching to a CDN without any cached content may cause a major hit to the origin servers and potentially a notable consumer quality degradation.
Many broadcasters and content distributors use multi-CDN setups for multiple reasons. The primary reason is of course securing the service quality, both in terms of quality and availability/redundancy of the service. Using multiple CDNs also protects from vendor lock-in. And with the efficient CDN switching techniques used today, it also helps greatly with efficient cost management.
CDN Selection Criteria
So far only QoS (including availability) and price has been mentioned as the main reasons for CDN switching, but multi-CDN solutions today have quite sophisticated use cases. CDNs are used in parallel for certain traffic amounts, traffic types (live, VOD, nPVR etc.), geographical regions, price ranges and for many other reasons. The rules can be made very granular and for lots of parameters.
Static Rules
Static rules stipulate what CDN to use for specific geographies, devices, stream types (VOD or live), and much more. Static rules are always applied equally regardless of streaming quality.
Static rules are often made to handle business or technical circumstances. In many cases CDN prices vary between different traffic volumes or commitments. In these cases, one CDN is used to a committed traffic volume and other CDNs deliver the exceeding traffic.
Dynamic Rules
Dynamic rules depend on situation, usually quality. The quality of the services is continuously measured and serves as decision basis for the CDN selection, either globally across the service, regionally, or locally per client and stream.
The most common example is to measure how well a CDN is performing in a certain region and make sure that clients switch to the highest performant CDN.
According to the CDN selection criteria depicted in fig 2, Finland is divided by VOD and live content. Apparently CDN A is best used for live content in Finland whereas VoD content is best served according to global QoS metrics. In Sweden there seems to be a commit-based rule where 10 PB is committed to CDN B. In Norway CDN C seems to be the best for serving content to mobile devices while desktop devices are served by the currently best performing CDN in that region.
CDN Selection Techniques
The CDN selection mainly occurs when client asset requests are initially received. At that point the CDN selections is made to determine which CDN should serve the asset. Some CDN selection techniques also provide mid-stream selection making sure that a higher performant CDN seamlessly takes over the content delivery if the first CDN would suddenly face performance problems during an ongoing streaming session.
We differ between two main technical base principles for CDN selection; Server side CDN selection, and Client side CDN selection.
Server Side CDN Selection
Server Side CDN Selection techniques deliver information to the client about where assets can be retrieved. The client does not make any decision itself but follows the URL paths to each content segment as directed. With Server Side CDN Selection the client may be completely unaware of multiple CDNs but blindly follows URL paths.
There are two main techniques to Server Side CDN Selection — DNS based CDN switching and Manifest Rewrite Based CDN Switching. Each of them briefly described below.
The main advantages of Server-side CDN selection is that it is client agnostic. All the functionality resides centrally in the network and clients do not have to be integrated with the solution. This is of course very valuable as there may be a large variation of clients associated with a streaming service.
Single point of failure is usually referred to as the main drawback of Server side CDN selection. Naturally both DNS and manifest rewrite components must be kept redundant and scalable.
DNS Based CDN Switching
In DNS based CDN switching the DNS system points out CDNs according to performance data. Note that the video source URL remains constant, but the DNS-lookup will resolve different paths depending on the selection criteria.
By changing the DNS TTL (time-to-live) value, DNS based CDN selection can be made more granular enabling mid-stream switching. This could be useful when the primary CDN suddenly faces performance degradations. The CDN switch is seamless, given segmented streaming formats and freshly populated CDN caches.
Simplicity is the main advantage with DNS based CDN Switching. The disadvantage is usually that lower TTL values, for mid-stream switching, increase DNS overhead traffic. Also, the DNS infrastructure itself may become a bottleneck with an increased number of requests.
Manifest Rewrite-Based CDN Switching
This method is quite more advanced than most CDN switching techniques. With manifest rewrite based CDN switching, the content manifest is rewritten changing the video segment URLs pointing out the currently most appropriate CDN. The manifest rewrite happens just-in-time and uniquely for each client and session (remember just-in-time packaging from other articles?). This technology also resembles the one that is used for SSAI (Server-Side Ad Insertion) described in the OTT Ad Insertion article.
Manifest Rewrite-Based CDN Switching also supports mid-stream switching. For live OTT streams new manifests are continuously created and rewritten. For VOD content where only one manifest file is distributed, the manifest rewrite occurs only once, but points out a prioritized list of CDNs. If the client detects segment download issues, it automatically switches to the next URL in the list.
The complexity with Manifest Rewrite Based CDN Selection is that is resides in the traffic flow — it delivers the actual manifests. Therefore, the server-side CDN selection technique is usually built as its own CDN with multiple nodes rewriting and delivering the manifests.
Note in fig 4, that the selector does not only send rewritten manifest files. It also distributes video segments. These video segments are delivered for CDN analysis reasons. More about this in the Collecting CDN Performance Data below.
Client Side CDN Selection
In client side CDN selection techniques, the client plays a role in selecting the most appropriate CDN. After usually rather simple integrations, the client may take more or less active decisions. Client side CDN selection techniques still rely on central servers to collect information about CDN performance, or at least provisioning CDN intelligence.
The benefits of Client Side CDN Selection is that it provides an unmatched granularity in CDN selection. The selections are made individually with 1sthand info on customer experience and CDN performance.
The main drawback of Client Side CDN Selection is the fact that the technique is client dependent. Integrations need to be made on all types of relevant clients from mobile platforms to smart TVs, and later maintained through uncontrolled client platform upgrades hopefully without any service downtime.
Each of the two main techniques of Client Side CDN Selection are described in a separate section below.
Server-Side API-Based CDN Switching
In Server-Side API Based CDN Switching the added client functionality uses API calls to request CDN information at video streaming session start-up. All CDN performance information and selection rules still reside server-side.
Server-Side API Based CDN Switching offers the same level of control as Server-Side CDN Switching techniques and lets the client request for CDN information.
Despite the drawback of client residing code, the client impact is very small. Instead, the lack of mid-stream switching is considered the main disadvantage of this solution.
Client Side CDN Switching
Client Side CDN Switching is completely implemented in the client. At start-up, the client receives enough information about available CDNs, and based on the real-time performance conditions the client will switch to the most appropriate CDN at any time.
The drawbacks with client-based solutions peaks with Client Side CDN Switching because of the code complexity residing in the client. However, this method is often the most accurate quality wise since each client makes own decisions based on local and relevant data.
Client Side CDN Switching supports mid-stream switching.
Collecting CDN Performance Data
CDN performance data can be measured in different ways and sometimes depends on the CDN selection technique itself. In most cases, the basic principle is measuring latency and response times trying to download files from CDNs. The more granular these measurements are, the better performance intelligence.
The least granular level is measuring the download of small dummy files of a few kB from each CDN. Sharpening the region and the type of downloaded files increases the granularity and accuracy of performance data. Top granularity and performance data are achieved by measuring each individual client and continuously through each individual video stream (for video service related CDN selection), and of course download real video files rather than dummy files.
One CDN selection technique uses a completely different performance analysis principle: Manifest Rewrite-Based CDN Switching.
As mentioned above, the main principle for CDN switching is to rewrite manifests to direct clients to the best performing CDN. But the same technique is used to deliver actual video segments too, and measure response times of the client, retransmission rates, request frequency and much more. Comparing results between various clients and video sessions can also reveal bottlenecks in the last mile delivery instead of the actual CDN.
Finally
To secure availability, quality, and performance at an acceptable cost, multi CDN setups are becoming standard in the media industry. But what about geographical areas where public CDNs fall short? And how to prepare for unknown peak levels when planning a football world championship? Any reason to build an own CDN? And are there any other ways to deliver content at scale?
The third and concluding article about OTT content delivery answers these questions.
Eyevinn Technology is the leading independent consultant firm specializing in video technology and media distribution, and proud organizer of the yearly nordic conference Streaming Tech Sweden.
