OTT Content Delivery– CDN Alternatives

Written by: Boris Asadanin, Streaming Media Consultant and Partner at Eyevinn Technology

Introduction

In this third and concluding article about OTT content delivery, we explore various types of CDNs, alternatives to CDNs, and aspects when building or buying CDNs.

This is the third CDN article concluding the content delivery topic. The previous articles describe what CDNs are, how they work, and how multi-CDNs are built.

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.

Types of CDNs

Public CDNs

Enter-Deep Architecture CDN

The advantages with lower latency and performance is usually counter-balanced when maintaining the high number of POPs. Configuration and changes propagation may be challenging. Also, due to the many number of POPs, it gets too expensive for each POP to hold a large cache or even all functionality. Smaller caches create a higher number of cache misses and thus generates downloads from other POPs in the CDN network.

Super-POP Architecture CDN

With few POPs the maintenance and configuration propagations are rather effective. Also, the larger POPs make sure that cache misses are kept low. However, fewer POPs require carefully planned POP locations for optimal connection performance and peering agreements efficiently reaching any client in the region. And if any of the few POPs fail, the clients will be directed to other POPs usually much further away from the failing one, potentially generating higher latency.

Fig 1. Enter-deep architecture (left) with multiple smaller POPs distributed all over a geographical area and ISP networks. Super POP architecture (right) with one large POP well connected to the entire region.

Proprietary CDNs

Building private CDNs requires lots of technical knowledge and continuous work to make sure that any traffic fluctuations are prepared for. And traffic peaks may become a scalability nightmare since they come rarely but nevertheless require up-front investment and preparation.

Being very CAPEX heavy, proprietary CDNs usually become very cost effective operationally with a steady base traffic load.

Hybrid CDN

Hybrid CDNs may be used for various improvements to content distribution. Improvements like enhancing performance in certain regions by adding own POP locations, increasing control over certain streaming services by for instance pushing VOD traffic to own POPs, or simply add a supplementary remote storage location. Any quantity of self-built components shapes a Hybrid CDN.

Fig 2. Hybrid CDN — Public CDN enhanced with added locations and storage. In the North also enhanced with packager to compensate for lower network backbone throughput.

CDN Alternatives

P2P (Peer-to-Peer) CDNs

Fig 3. Peer-to-peer video network. Clients share content directly between each other.

In P2P content distribution origin may be tremendously offloaded, vendors in the market talk about figures up to 90%. Instead of downloading video segments from a CDN, why not just download them from the other client? The more popular a live event is, the more clients are involved in the content sharing. And the traditional CDNs remain unaffected by the traffic increase.

As previously mentioned, P2P technologies are used to offload traditional CDNs rather than being the single solution to scalable content distribution. The reasons are simple; exposing content origin servers allowing consumer clients on the open internet to directly request content files would be a serious security threat with probable DDOS impact.

Fig 4. Complete CDN setup with P2P CDN as primary last mile delivery. Note the bottom hybrid CDN (enhanced with added proprietary nodes).

What’s Holding Up the Parade?

There are a few important aspects holding back the quick adoption of P2P content distribution. Traditionally the issue has been that P2P CDNs require subscribers to give up part of their device resources — upstream traffic, local storage, CPU cycles and battery consumption.

Fig 5. Old issues with P2P technology requiring client resources. 2019 = issues solved?

However, some P2P vendors are able to configure their technology to use only clients on fixed connections for content sharing. This usually solves most of the concerns since fixed clients are usually more well equipped, especially on power and connection. It also solves a much more alarming problem; mobile networks are usually not dimensioned to have upstream traffic added. This could potentially threaten the downstream traffic which is unacceptable. But again, having only fixed connected clients sharing content, there is no need to worry.

There are more worrying disadvantages with P2P content distribution — disadvantages that are becoming more apparent as new video related services are emerging. Following two major services are today not compatible with P2P content distribution:

Server-Side Ad Insertion (SSAI)

Users of P2P content distribution are left to use Client-Side Ad Insertion, in which the client is ad aware and explicitly asks an ad server mid-stream for ad content, before it resumes playing the video stream. This is however one of the main disadvantages with Client-Side Ad Insertion. As the client is aware of the ad break, it is susceptible to ad blocker software.

Read more about Ad Insertion technologies in the Ad Insertion articles. It is interesting.

Content Watermarking

Priority 1: Service Availability

The Joker: Multicast Distribution

Fig 6. Traditional unicast (left) vs. multicast (right) streaming. Unicast is one-to-one while multicast is one-to-many and thereby scales perfectly for live event streaming applications.

Multicast is not a new invention. Multicast, or streaming one-to-many, is an old well proven technology used by many applications. In the video space, IPTV (described in the Streaming IPTV article) has always used multicast to stream live content efficiently to any sized audience. However, network protocols associated with multicast streaming has so far been suited only for private or closed networks, and thus unsupported on the open internet. Besides, adaptive bitrate streaming, explained in the Internet Video Streaming — ABR articles, where clients adapt to network fluctuations has so far been incompatible with the multicast principle.

Current research projects are breaking the barriers between the two incompatible technologies enabling adaptive bitrate streaming over multicast. Streaming major live events over multicast will reduce server resource consumption (for live streaming) to close to zero.

Another initiative; LTE Broadcast (a.k.a. LTE Multicast) enabled by 3GPPs evolved Multimedia Broadcast Multicast Service (eMBMS), already makes Multicast content streaming available within eMBMS LTE mobile networks. While the technology emerged already back in 2014, it has still not taken off properly. The technology must be explicitly implemented in mobile devices and mobile networks. Samsung was an early adopter on the client side, but only a few global operators have so far added the support. Critics point at slow network upgrade cycles and that the rollout cost can’t justify the business case. Besides, many are probably waiting for the 5G network rollout

Either way, Multicast for ABR streaming is ground-breaking enough to be covered in a separate article.

Aspects of Build vs. Buy

Let us have a closer look at the business cases of these two alternatives.

Buy

Setup and configuration can be made within hours or days and no technical CDN knowledge is required.

Build

A privately built CDN must be continuously maintained. This is a common misconception; a complete working CDN will not run by itself forever. It has to be maintained. The traffic flow varies constantly, as the underlying network infrastructure (routers and connections) and other parameters.

Last but not least, don’t forget the hardware depreciation. But hold on, this may actually be a possibility. Building CDNs with public or private cloud technologies, owners may scale their CDN on demand and use available system resources for other tasks during low traffic periods. The platform is still required for other IT related services offered by ISPs, Telcos and others. Adding the CDN application as another component on top of an already existing cloud infrastructure may be a wise option.

Fig 7. Building CDN components using cloud software to avoid hardware depreciation.

Future Trends

https://www.streamingmediablog.com/2019/05/latest-cdn-pricing-trends.html

The cost saving in building and maintaining an own CDN is rapidly shrinking. In parallel, decreased revenue per GB delivered is made up by including other technologies with the CDN. The public CDN market is going through heavy consolidation. Technologies such as more sophisticated security offerings, AI applications specifically for video (and other areas), and other video related services like storage, transcoding and packaging etc. are bundled with CDN in a more complete offering.

Summary

Fig 8. Common CDN type setup for various traffic amounts used by Telcos and network owners with P2P gaining popularity. Without a private CDN the traffic is sent to public multi-CDNs.

Building an own CDN may look intimidating and expensive, but with a stable base traffic flow a private CDN may still be cheaper and offer better control than buying CDN services. Don’t forget, the public CDN companies are in fact building their own CDNs. The only advantages they have is their CDN expertise and probably a generous hardware volume discount.

To minimize the risk when starting a new video streaming service, keep the CAPEX low not to end up with lots of infrastructure. And in the consolidating market, make sure to keep all your streaming platform options in perspective rather than considering CDNs and other components separately.

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.

We are consultants sharing the passion for the technology for a media consumer of the future.