Imagine it’s the Olympics and millions of viewers are tuning in at the same time to watch the live stream. The most challenging scenario for content providers: The content has to be delivered fast, reliably and cost-effectively, while Content Delivery Networks (CDNs) reach their limits.
In this blog post, you will learn more about:
- CDNs and their limits
- Default approaches to handle performance issues
- Content Steering as an innovative approach that gives back control to content providers
At the limit: CDNs face many challenges
Content Delivery Networks (CDNs) are a geographically distributed group of servers that work together to provide fast delivery of internet content to the user – everything from static webpages to live streams.
Possible limitations
As these networks are vast and accessed by millions of users, sometimes there are delivery problems. Network congestion, peering limitations with Internet Service Providers and unexpectedly high loads are just three examples of common challenges CDNs face as they try to distribute content to end-users.
To tackle these issues that threaten to seriously harm user experience, content providers often use multiple CDNs in parallel, employing a “multi-CDN” distribution strategy.
However, there is not just one default way to implement multi-CDN – and all existing solutions bring limitations.
Typical ways multi-CDN and load-balancing are realized in the world of streaming is via either video player-initiated Content Delivery Network switching (player-initiated CDN switching) or Domain Name System-based multi-CDN (DNS-based multi-CDN) – both of them we will explain below.
With the multi-CDN approach, the same content is stored simultaneously on different content delivery networks, meaning content delivery networks managed by different CDN providers. Serving content over a multi-CDN infrastructure requires a lot of coordination and the two commonly used methods to switch between CDNs are the player-initiated and the DNS-based approaches.
Player-initiated switching: advantages and limitations
The first player-initiated approach to assign clients to different CDNs is by providing an API which tells each client from which CDN the content should be fetched. But this requires the maintainance of an API and client side logic that handles this information. Furthermore, a client can not be switched mid-stream between CDNs, but only before playback has started.
Another approach is the use of the fallback mechanism in the event of playback problems. In this case, the client consults the so-called “manifest file” when it experiences fatal playback problems (e.g. excessive buffering or errors). This manifest allows to add fallback URLs for each stream, which can point to a different CDN. In case of fatal playback problems, the player checks the manifest file and works its way down the list of URLs until one of them allows for problem-free streaming.
There are two main limitations to this approach. Firstly, many streaming providers don’t use it and most manifest files only point to one CDN. Secondly, in the cases when manifest files do have URLs pointing to different CDNs, content providers are not in control of when a player switches or exactly where to. This can result in uncontrolled behaviour, like individual CDNs suddenly being flooded with requests.
DNS-based multi-CDN: advantages and limitations
In the case of DNS-based multi-CDN, content providers use a DNS server as a kind of orchestrator to define which CDN each client gets connected with. For example, when a user visits a website (e.g. www.movies.com), the DNS server stochastically assigns the user to one of the available CDNs.
As an example, user 1 gets assigned to CDN A and user 2 to CDN B. Then, the assignment starts all over again and user 3 gets assigned also to CDN A, user 4 to CDN B, and so forth. By assigning each user to one specific CDN, the overall load can be distributed among all CDNs in use.
This technique enables the creation of distribution rules, for instance, to specifiy that 70 per cent of clients should fetch their content from CDN A and the rest from CDN B. These distribution rules can be introduced when desired, not only upon playback failure, so CDN switching can happen mid-stream. There is a catch, though: it takes a long time until all clients that should be redirected to the new CDN actually are, as the DNS resolution is cached on the client.
Another limitation of DNS-based multi-CDN is that control is exercised on the group level, not the individual level. It is not possible to target specific viewing sessions. For example, if 10 out of 100 Londoners watching a stream on an iPhone 13 are experiencing long buffering times, a content provider cannot redirect only those 10 viewers to a different CDN, the provider must chose to either move all 100 clients or none of them.
Why existing approaches aren’t enough
To summarize, player-initiated switching is a fallback mechanism triggered upon playback failure and DNS-based multi-CDN is a tool for broad distribution strategies. Both are powerful, but sometimes they are not enough. Content providers might want CDN switches to happen for non-critical reasons, such as meeting contractual volume commitments, or guide specific clients to specific CDNs. Other approaches, like server-side manifest manipulation, face issues on their own.
However, now there’s a new solution available offering loads of new flexibility while being standardized and working off-the-shelf.
Regaining control with Content Steering
That’s where Content Steering comes in – a mechanism for dynamically switching Content Delivery Networks (CDNs).
Content Steering gives back control to the content providers’ side via a “Steering Server”, which determines
- when CDN switches occur – in near real-time, even after playback has started.
- where to CDN switches occur – which alternative CDN should be used instead of a given CDN.
The technology was introduced by Apple in 2021 as a new feature of its streaming protocol, HTTP Live Streaming (HLS). In 2022, the technology was adopted by the DASH Industry Forum as an extension of their streaming protocol, Dynamic Adaptive Streaming over HTTP (MPEG-DASH), and also by hls.js, a JavaScript library that implements HLS. This means that content steering is supported out-of-the-box by Apple devices (i.e. iPhones, appleTVs or MacBooks), as well as all standard web browers (e.g. Chrome, Firefox, Edge, Safari). In other words, there is no need for an additional library, API or DNS server which realizes the CDN switching; content providers can easily implement and maintain content steering without any overhead.
In summary, Content Steering gives content providers control, flexibility, and real-time responsiveness.
How does it work?
Let’s go back to our example: It’s the Olympics and millions of viewers are tuning in at the same time to watch the live stream. As a surge in viewers is expected and to provide for additional redundancy, the content provider has taken the decision to distribute all viewers by directing them to two different CDN providers (CDN A and CDN B) – in our example starting with 50 per cent load for each.
Clients (i.e. video players) which support Content Steering regularly communicate with a steering server. In order to achieve the desired CDN load-balancing, the steering server replies with two different responses to the clients in a 50/50 split using a JSON payload.
Half of the clients (orange color) receive the following response from the steering server telling them to prioritize CDN A:
{
"VERSION": 1,
"TTL": 30, //seconds until next steering server communication`
"RELOAD-URI": "https://example.com/steering-server",
"PATHWAY-PRIORITY": ["CDN_A", "CDN_B"] // CDN provider identifiers
}The other half of the clients (green color) get this response in order to prioritize CDN B:
{
"VERSION": 1,
"TTL": 30, //seconds until next steering server communication`
"RELOAD-URI": "https://example.com/steering-server",
"PATHWAY-PRIORITY": ["CDN_B", "CDN_A"] // CDN provider identifiers
}The payload contains the version number of the protocol (Version), the number of seconds that the player should wait before requesting an update from the steering server (Time To Live or TTL), the URI where the steering server can be reached (Reload-URI), and a priority-ordered list of CDNs from which the player should fetch the video content from (Pathway-Priority).
In the first example, the priority list tells a player to request content from CDN A, and only if this doesn’t work for, to fall back to CDN B – vice-versa for the second example.
While something similar can also be achieved with one of the “default” approaches described before, there are many reasons why a content provider would want to dynamically treat a sub-group of the clients differently in an easy manner.
Based on quality aspects, connectivity or economic and ecological criteria, the content provider now wants to treat a sub-group of the clients differently. In our example, a selected sub-group is entirely directed to get the content from CDN B.
In order to trigger the desired CDN re-balancing just for the selected sub-group, the Steering Server replies accordingly only to the affected clients telling them to prioritize CDN B:
{
"VERSION": 1,
"TTL": 10, //seconds until next steering server communication`
"RELOAD-URI": "https://example.com/steering-server",
"PATHWAY-PRIORITY": ["CDN_B", "CDN_A"] // CDN provider identifiers
}Mind that for these specific clients the TTL was reduced to enable a fast re-evaluation and minimum delay option to re-balance again.
Users of this sub-group will now seamlessly continue to watch the stream while being served from a different CDN following the dynamic decision as taken by the content provider.
To see Content Steering in action and understand how it can be coupled with a quality aware realtime data, read more about EINBLIQ.IO’s approach here and try our demo
Curious to know more? Contact us at: team@einbliq.io