The ideal solution would be to combine all these approaches, but the last one is probably the easiest to implement, allowing immediate Quality of Service (QoS) improvement. This article will explore different multi-CDN approaches for multiscreen distribution, weighing the technical benefits and drawbacks of each method.

A Thorough Comparison of the Different Approaches to Using Multiple CDNs

The simplest approach for relying on multiple CDNs is using a static CDN selector tool. Under this method, the content provider applies fixed rules, allocating a CDN based on certain information such as the geographic location of the end-user, the end-user NSP, the time of day when the request is made, or the type of content (free vs premium). Based on prior global knowledge of CDN behaviors, such as transit contracts between NSPs and CDN providers, local champions, etc., content providers can choose which CDN to use based on how they anticipate it will perform in various situations.

One of the key benefits of this approach is simplified implementation. Deploying static CDN selectors can be done easily, without impacting the application side. Additionally, static CDN selectors cover common use cases, especially when the region affected by the service is spread across different countries. The main drawback of this type of solution is that it does not take into account the QoS of the different CDNs. If the CDN encounters a failure, the end-users in the region will not be well-served.

A viable alternative solution is depending on QoS criteria for CDN selection. QoS-based CDN selectors rely on a shared pool of information, whereby an agent is installed in the devices. The application communicates QoS data about the CDN to a common database. This information is then used to allocate a CDN after a session request has been received.

With a QoS-based CDN selector, content providers get a global view of the various CDN performances. The main issue with this type of solution is lack of dynamicity. QoS information gets old very rapidly. Even when an update takes place every minute, the CDN selector may not sufficiently take into account all of the local failures. This could lead to a denial of service or drop in the session. The other problem with this approach is that content providers are utilizing a shared database with their competitors. This makes it hard for content providers to differentiate their service.

An effective way that content providers can fix the shared database issue is by relying on session-based switching leveraging private information. In this case the CDN is selected at the beginning of each session, according to feedback from subscribers. Content providers own the information. It’s not data that is going to be shared with others. Unfortunately, the CDN allocation is done once for the entire duration of a session; therefore, it lacks dynamicity. If the elected CDN fails, the session will be interrupted. Moreover, one CDN may not be the best fit for the whole session.

Another solution is mid-stream switching. With this approach, the QoS is regularly evaluated by an agent in the application, which requests the same chunk of content from different CDNs. The CDN that provides the fastest service with the highest bit rate is selected for a given time.

This approach is much more dynamic than some of the others discussed above, as the selector takes into account the changing conditions of the CDNs. However, there is an overhead issue. Since similar data is requested several times from different CDNs, content delivery costs increase. Also, content providers can only use one CDN at a time with mid-stream switching. If the CDN encounters a failure in the timeframe for which it has been allocated, the session will stop.

The final — and optimum — solution is for content providers to rely on several CDNs simultaneously. This method employs a user agent that requests different chunks of content from various CDNs, assigning more jobs to the ones that answer rapidly and with the highest bitrate. The CDN selector builds the stream from different chunks, placing CDNs that do not perform well into quarantine.

Using multiple CDNs at the same time is optimal in terms of dynamicity since all the CDNs can be requested concurrently. It’s also proven to maximize service uptime. If a CDN fails, there is no impact on service continuity. Moreover, there is no overhead because all of the information that is requested is used. Content providers are not asking for the same information from different CDNs. Rather, they’re utilizing different chunks of content to rebuild the stream in the application. Ultimately, content providers that want to offer multiscreen need the ability to select the most adapted CDN according to their specific requirements and use cases, and this solution answers that requirement.

Conclusion

While there are numerous options available, in terms of CDN selector tools, the best approach involves using multiple CDNs simultaneously. Compared with other methods, it addresses content providers’ requirements for dynamicity, service uptime, low cost, and superior QoS.

Broadpeak’s umbrellaCDN CDN selector tool ensures that content providers can always choose the most adapted CDN for delivering video content. It offers a variety of advanced capabilities, including CDN Diversity, a new technology that allows content providers to dynamically evaluate the instantaneous quality of several CDNs as a service in order to deliver the content with the highest quality possible.