We LOVE cookies because they give you a better browsing experience. We hope you like them too. But if you find the cookie monster a bit scary, you can find out how to manage it here.

Blog

Optimizing video delivery using in-session CDN management

So far, our tech blog series on the challenges the OTT industry is currently facing when delivering TV content has discussed how sessions are set up for initial CDN selection and how quality of experience can be measured server side for OTT streaming.

Now, as more and more streaming services rely on multiple CDNs to ensure content delivery, in-session CDN selection has become increasingly important. According to a recent survey on multi-CDNs sponsored by Fastly, 26% of broadcasters already have a multi CDN strategy in place.

So, for our third tech blog, we are exploring in-session CDN selection. We will look at the methods used today for in-session CDN selection: client-based, server-controlled clients, DNS-based and manifest rewrite, and analyze the pros and cons of each one. 

To understand the importance of in-session CDN selection, we’ll point at the limitations we discussed in our first blog: The initial selection of a CDN makes it possible to distribute clients as they start up a new streaming session and is an important part of having a multi CDN strategy for a service. But, to be able to optimize the delivery and ensure the best possible quality of experience for customers this is often not enough. In particular for large sports events where the conditions change constantly as capacity increases, CDNs and the networks are pushed to their limits. Therefore, the ability to redistribute ongoing sessions to other sources without interruption, and to add new resources are critical and should be done in a tight loop during ongoing session with low-delay quality supervision of the service.


Client-based CDN selection using alternative sources in the manifest

In HTTP streaming, the client downloads manifests and segments from the CDN as it sees fit. It is therefore natural to add selection of alternative CDNs to the client responsibilities. In fact, both HLS and DASH make it possible to list alternative CDNs in the manifests. In HLS, this is done by specifying the same track twice with different URLs in the master playlist, while in DASH, this is done by specifying multiple BaseURLs.

The combination of Adaptive Bit Rate (ABR) streaming with multiple CDN selection is a two-dimensional space. If the client experiences a reduced download speed, it will typically switch to a lower bitrate variant, even though the other CDN may provide a higher speed. However, if a segment can’t be downloaded, the other CDN will be used instead, acting as a backup source rather than something that’s used to purely optimize QoE.

Pros:

  • The client has the most complete view of download history and detailed information of buffer levels and user interaction.
  • The change of CDN can be immediate, meaning a stalled or slow download can be interrupted.

Cons:

  • The client does not know the status of the CDNs it is not using. Every client will only base its decision on what it sees, not what other clients might be experiencing.
  • Since clients are autonomous, there may be an avalanche of clients moving simultaneously from one CDN to another at a dip in delivery, causing even more problems.
  • There is no standard for how different clients handle multiple sources in the manifest, so the selection behavior is unpredictable.
Server-controlled client source selection

If you have complete control over the client, you could let it micromanage the CDN selection from a remote server. The input for this decision could be based on both the client experience and the experience from other clients.

For this to work, there must be a proprietary protocol between the server and the client which is giving it orders to act on.

Pros:

  • A system-wide change of CDN can easily be made by moving clients based on any metric inside or outside the client’s visibility. Examples of metrics could be cost or geography.
  • The client can be moved quickly to another CDN without any service interruption.

Cons:

  • No standards, proprietary protocols and code need to be inserted into the client.
  • Server-controlled client selection needs client integration at both the player and the network layer.
  • The client needs to adapt to fit in many different ecosystems, including SmartTVs and old mobiles.
DNS-based

DNS-based CDN selection is a simple but crude method. It works relatively well for initial CDN selection by repointing the DNS to another CDN even though no client information, except the IP address, is visible to the DNS server. However, it is not well-suited for in-session selection since you can’t control when the DNS lookup is done. Furthermore, you can’t force the clients to do another lookup when you need to change the delivery. DNS timeouts are imprecise and open TCP Sockets will not be affected. Therefore, DNS-based CDN selection is not a flexible alternative for in-session CDN selection.

Manifest rewrite

With Manifest rewrite, the URLs for individual segments change by rewriting the manifest. This works best with HLS which has complete URLs for each segment in the media playlists, so you can repoint any segment to any source.

For live, the segment list is fetched again by the client as new segments are created, and a server can change the latest segment to point to another CDN that the segments were not pointing at before, which effectively moves clients to the new source in a controlled fashion. However, this requires an explicit list of URLs and, thereby, does not work with DASH which uses the same URL for all segments in a bitrate variant.[1]

Changing the manifest during the session does not work for VoD since the manifest or playlist is only downloaded once when the stream is initialized. All segment requests will therefore go to the CDN, or CDNs, decided at the start of the session. After the start of the session, it is committed to the initial decision. Some solutions use this method to redirect part of the traffic to a separate server with diagnostic capabilities and collect server side metrics to gain insights into the session.

Pros:

  • Manifest rewrite can be used on a per-segment basis.
  • It sends every 10th segment to a separate CDN that can produce server insight about the session.
  • It is supported by HLS Live Media Playlists, so no client-side development is needed.

Cons:

  • Manifest rewrite does not work for DASH or non-live streaming i.e. VoD.
  • Only sessions at the live point can be moved to another CDN, since that is when the client fetches new playlists between every segment.
Conclusion

With client and server development and integration, as well as proprietary protocols, it is possible to make a server-controlled CDN-move in the client.

Another interesting option is to list multiple CDN URLs to the client via HLS Master Playlist or DASH Manifest, and let the client choose itself.

Finally, if the dominating streaming traffic is live HLS, manifest rewrite gives detailed control of where each segment is fetched.

Torbjörn Einarsson, Expert, Media protocols and codecs, Edgeware
Kalle Henriksson, Founder, Edgeware

 

COMING NEXT
In our next post, we will continue the blog series by presenting our own new solution which addresses the challenges we have highlighted. It’s available here.

READ MORE
Learn more about Edgeware’s new session control platform, StreamPilot. Would you like to book a live demo or set up a meeting, please contact us here.

NOTES
[1] Theoretically, one can insert a new Period in a DASH manifest when the CDN part of the URLs change. But playback over period boundaries is not smooth. Another possibility in DASH is to use SegmentList. However, this is not aligned with the interoperability specifications of DASH-IF and other bodies.

ARE YOU READY FOR TV BEYOND BROADCAST?

Fill out the form below and we will get in touch with you.