When streaming on-demand or live video, issues with a particular CDN can impact the user quality of experience (QoE) if the CDN struggles to fulfill the requests. If the player has access to multiple CDNs, switching to another CDN or using multiple CDNs simultaneously might help maintain a good user experience. Generally speaking, most streaming services use a multi-CDN delivery approach for redundancy and business purposes.
Why Do Streaming Platforms Want to Switch CDNs?
There are various reasons a streaming operator may want to utilize CDN switching:
- Performance: A CDN performing poorly in a specific geographic region may compromise QoE. When this happens, it could adversely affect video engagement (how long viewers watch) or even result in churn.
- Capacity: A CDN may sometimes develop capacity issues because of competing traffic on its network.
- Traffic commits: A streaming platform may sometimes want to switch because of contractual obligations. For example, CDN A may need to get 35% of traffic, while CDN B may need to get 65%.
- Cost: Streaming platforms may want to switch to CDNs because of lower costs in specific regions or at specific times of the day.
How Does CDN Switching Work?
Determining the best CDN at a given time is not a very straightforward task. First, there is business logic in every streaming service that will limit which CDNs can be used when and for how long. This logic considers the availability, cost, quotas, and other relationships between the streaming service provider and CDN operators. As a result of this business logic, the manifest file provided to a player lists the possible CDNs along with their priority. The figure below illustrates a simple multi-CDN delivery approach.
There are two primary means by which CDN switching can happen –server-side and client-side.
Server-Side Multi-CDN Switching
In server-side switching, a specialized server (often called a content-steering server) analyzes data from various sources, such as the clients, CDN logs and synthetic agents. This data is then used to determine which CDNs to utilize for delivery, and individual manifests are modified for player sessions and pushed down to the appropriate clients.
Client-Side Multi-CDN Switching
In client-side switching, the player runs some heuristics to determine the individual performances of different CDNs and picks the best-performing one for the subsequent request. The heuristic could be as simple as pinging the candidate CDN edge servers and determining the one with the lowest ping time. Or, the heuristic could be more complex and consider the past performance data.
An Overview of Multi-CDN Switching Approaches
There is little consensus on the best way to accomplish multi-CDN switching. Some streaming platforms have built their own solutions (both server and client-side), while others have engaged with third parties who can provide a hybrid approach, utilizing both server and client-side business logic. Of course, there are pros and cons to each kind of approach. Muvi has put together a nice blog post examining the different approaches to CDN switching:
| Type of Switching | Pros | Cons |
| DNS-based | This is the simplest of all solutions since the source video URL always remains constant. | Switch delay is more time-consuming, ranging from 300 seconds to even five minutes in case of CDN failures. This can immensely hamper the user QoE. |
| On-the-fly manifest rewrite | Better user experience due to midstream switching eliminating the need for hard refresh during video playback.
No matter the volume of simultaneous session resets, this method reduces the chances of a cascade effect that may hamper the video workflow. |
Rewriting the manifest can sometimes bring about errors.
Midstream switching is not completely seamless, and takes time for the server to understand that a particular CDN is unavailable. |
| Server-side | It is a relatively simple CDN switching method to implement since changes happen in the server itself that is easier for the operator to control. | Page loading may take some time, adding to delays.
Since CDN switching is based on the collective data from many clients, it does necessarily consider the unique conditions of the actual clients. |
| Client-side | QoS data is almost accurate as it is fetched based on individual clients’ local and real-time performance metrics.
Seamless midstream CDN switching is possible. |
It is a complex procedure to implement when built in-house due to the code complexity of the algorithms that requires detailed planning. |
Although the Muvi blog post provides a good, high-level overview of different multi-CDN switching approaches, selecting the right one can be complicated. What is needed is data on each method’s effectiveness and an understanding of the complexity of implementation.
Exploring Multi-CDN Switching: A New SVTA Project
In this project, the SVTA Players and Playback group will look at the different approaches to multi-CDN delivery and provide an analysis to help streaming platforms select the best option for their specific business requirements. In addition, the group will propose a client-side solution using a JavaScript load balancer and SDK compatibility layer. This solution may encompass different heuristics for CDN selection, and one of our goals is to study the impact of client-side CDN switching on a client’s rate-adaptation algorithm.
Project Details
This project will address this topic in three different phases:
- Phase 1 will gather data about the different CDN approaches
- Phase 2 will test the client-side JavaScript load balancer provided by Lumen
- Phase 3 will examine opportunities for harmonizing client and server-side solutions (such as DASH and HLS content steering methods proposed by DASH-IF and Apple, respectively)
Phase 1: Data Gathering
In this phase, we will set up a streaming environment using common components in a controlled environment. The testing will involve streaming multiple content types (live and VoD) to several different players from two CDNs. The data gathering will involve utilizing client and server-side CDN switching along with synthetic users to generate load. We will manually introduce performance issues into the system to force CDN switching. QoE data (gathered from the players) will be used to determine the impact of different switching methods. A blog post will be published with the data.
Phase 2: Proposed Client-Side JavaScript Load Balancer
In this phase, we will test client-side CDN switching donated by Lumen to the SVTA.
The Lumen load balancer code is a TypeScript library that serves as a client-side multi-CDN switcher for video streaming. For each video segment requested by the client player, the load balancer determines the best CDN to use and outputs a modified HTTP request identifying that determined CDN. The load balancer determines the best CDN by maximizing business rules and QoS scores, with initial values provided by an external interface. Once playback begins, an internal algorithm in the load balancer updates the QoS scores with each CDN request. To test this player (within the same environment as Phase 1), the code includes lightweight JavaScript integration with the open-source Shaka player.
Note that this client-side code is currently available for SVTA members to use. It is currently part of our SVTA LABS repos.
Phase 3: Harmonizing Client and Server-Side Approaches
In this final phase, we will test the Phase 2 implementation along with various server-side content steering (again, in the same environment as Phase 1) and gather data to show the effect of a combined client and server-side approach. The output of this phase will be to document optimizations that need to be made within proposed content-steering solutions from DASH-IF and Apple, as well as the client-side code tested in Phase 2.
Project Timing
The group will begin the project in early Q1 2023 with a proposed timeline for work and output:
- Phase 1: completion by end of Q1, publication of data by mid Q2
- Phase 2: completion by end of Q3
- Phase 3: completion by end of Q4
- Publication of final document: Q1, 2024
The Streaming Video Technology Alliance Player and Playback Study Group has the following objectives. First, to understand the technical challenges across the player and device ecosystem. Second, to document those challenges and identify possible projects for best practices, guidelines, and specifications.