← Blog

Multi-CDN Switching Methods Explained

by | Dec 7, 2022 | CDN

Implementing multi-CDN for video streaming has many benefits in terms of playback stability, cost, and quality of experience, but there is more than way in which this strategy can be put in practice, each one of them with its unique set of strengths and weaknesses.

In this blog, we take a look at the different multi-CDN switching methods available in the market today and how they work to help you understand which one best suits your streaming services’ needs. 


On-start CDN selection

Depending on where along the video play the selection of CDN happens, we speak of on-start CDN selection or mid-stream CDN switching

As its name suggests, in on-start CDN selection the CDN is assigned at the beginning of the stream and cannot be changed unless a “reload” occurs. A CDN is chosen based on a series of pre-defined business and audience rules — e.g. cost, video bitrate, or type of user — and the selection can be made via two multi-CDN switching methods: by using the Domain Name System (DNS) or through an application programming interface (API).


DNS-based CDN selection


The most common type of CDN load balancing solutions used today are DNS-based. The DNS translates requests for names like web pages into IP addresses, pointing end-user requests to the IP address of the hostname that will be serving that end user request (web page, video file, etc.). DNS-based selection methods like that offered by NPAW’s CDN Balancer leverage this tool to redirect the traffic to one CDN or the other based on business and quality rules.

DNS-based, on-start CDN selection is easy to implement, only requiring one line in the DNS configuration, and it allows for the balancing of all kinds of traffic whether it is static pages or dynamic content like video. Since it relies on a basic Internet tool, the DNS, this type of balancing method also offers full device backward compatibility.

However, DNS-based technologies have limitations when it comes to accurately identifying end-user traffic information, as ISP DNS caching and how the end-user setup is configured in the DNS server can interfere with end-user identification. In turn, this lack of accurate end-user information means DNS-based systems don’t allow for the application of advanced CDN selection criteria. Plus, they represent a single point of failure: in the case of DNS failure, the entire balancing system goes down.


API-based CDN selection

In this method, also available with NPAW’s CDN Balancer, the requests are handled via an API, which connects with the CDN selection system to determine what CDN to use in every situation. The API can be implemented server-side (directly integrated into the video provider’s backend) or client-side (integrated into the video player). Both methods can be combined depending on your needs, but client-side integrations are more complex as they demand the implementation of a plugin for every player (e.g. Android, Apple, Roku, etc.).

API-based CDN selection permits a much more granular selection of CDNs by having a better knowledge of the traffic to be balanced. All the necessary information for decision making (Profile, IP Protocol, Asset ID, User ID, etc.) can be forwarded in the API request and the response can be fully tailored to the profile of the request. But the advantages of this method don’t stop there. Each network change is monitored in real time and impacts the CDN selection process immediately. Additionally, in case of catastrophic failure, a default CDN is always selected ensuring service continuity.

The main drawback of this method: extra time. On one hand, as we have seen, it requires the integration of the API call into the service’s backend or end-user app. On the other, the whole API request process takes extra milliseconds and impacts the time it takes for the video to start.


Mid-stream CDN switching

As opposed to on-start CDN selection, where the entire video file is served with one CDN, mid-stream CDN switching divides the video file into video segments or chunks and allows for each one of them to be served by a different CDN.

Albeit more computationally intensive than serving the entire video with a single CDN, this approach gives content owners a more granular control over content distribution and allows them to play to the strengths of each CDN in their portfolio throughout the video play.  

Mid-stream selection can currently be implemented through two different multi-CDN switching methods: Active Switching or HTTP Redirect.


Active Switching

Active Switching is a new technology developed by NPAW and exclusive to its CDN Balancer. By collecting bitrate throughput information locally, a plugin integrated into the video player can detect CDN failures before they happen and switch amongst the originally designated CDNs for a seamless, transparent CDN switching.

This type of mid-stream CDN switching provides robustness against network failures and last-mile issues, and higher speeds can be achieved by aggregating the capacities of multiple CDNs. Additionally, the data collection and decision-making are done by the plugin itself based on a series of previously configured business rules. It also supports peer-to- peer (P2P), which makes it an ideal solution for live streaming events and channels, for which huge viewer concurrency can be a challenge.

However, the need for a plugin for every video player makes Active Switching a more complex method to implement, and it also requires the video segments to be synchronized across CDNs.

HTTP Redirect

Another method of implementing mid-stream switching is through an HTTP Redirect. These solutions make a redirection of every single video segment through an http 302 redirect, and thus requires a central server receiving all the video segment requests from each end user and redirecting them to a CDN or another.

The major advantage that this switching method presents is that no client integration is needed. However, each video chunk needs to go through the central server, meaning a single point of failure and performance and capacity issues. HTTP Redirect also introduces latency for every video segment and does not allow for any quality KPI to be included in the CDN selection process.