Open Caching is still relatively young. In fact, it is about 10 years younger than the first major introductions of D2C Broadcaster services like BBC iPlayer.
Almost a decade has passed since it was launched as a working group of the Streaming Video Alliance. Now that D2C streaming is firmly fixed in the latest strategies, plans and activities of Broadcasters all over the world, now is arguably the coming-of-age moment for Open Caching. So, what is the status of Open Caching today, what are its killer-apps that could catapult it forwards, and how does it fit into a multi-CDN model?
Open Caching Deployment
As highlighted in part 1 of this article, Open Caching has 3 primary components – Open Caching Node, Open Caching Controller, and Request Routing. These components have been defined and are partially specified by the SVA Open Caching Working Group. To deploy an Open Caching (OC) solution in its fully envisaged form requires the deployment of these OC-compliant software components in all layers of the CDN architecture. For many Content Providers that are using public CDNs today, this means that those CDNs must first implement OC-compliant software (or the Content Provider must build/buy a new OC-compliant CDN). Then the ISP CDNs that are OC-compliant (we refer to them as “ISP OC-CDNs” in this article) can be delegated to, enabling the onward delivery – and critically, the management – of the video streams.
This multi-CDN delegation approach is being worked out at a technical level. How it works commercially is another matter. Some of the major public CDN providers are not part of the SVA Open Caching Working Group – most notably Akamai and Microsoft. This is understandable given that once a stream is delegated to an OC-CDN, then all consumer-level egress from that point onwards is managed by the ISP’s OC-CDN. The business model of “Pay per GB” or even “Pay per Gbps” – with a cache hit rate of 95%+ - could mean somewhere between 90-95% revenue reduction for the Public CDN if they hand off to an OC-CDN provided by an ISP and their CDN provider. This is a significant commercial problem to overcome, which will be the focus of a future article.
Jason Thibeault, SVA Executive Director comments: “Adoption will not be driven by a single event. As network operators continue to implement open caching deployments, more companies will adopt it. But, ultimately, the pressure to adopt will come from the Content Providers or their platform operators that are looking for a better way to holistically manage all their caches across all of their delivery networks. This will probably play a key role in moving CDNs towards being Open Caching compliant.”
Without the solid commercial footing, Open Caching specs, as defined, are not able to be validated in full production mode because there isn’t yet a full multi-layered CDN ecosystem in which to validate them (however, to support development-stage interoperability testing, the SVA provides an API testbed to its member companies). Instead, pioneering solutions are being built today by leading OC proponents, such as Verizon, Qwilt and Velocix, for specific Content Providers with their own private OC-compliant CDNs, like Disney. Recent headlines from large ISPs including British Telecom and Telecom Argentina highlight the deployment of the Qwilt solution that is based on Open Caching specifications. Other sources explain that recently deployed ISP OC-CDNs are now being promoted more widely by those ISPs to the Content Provider market.
But these ISP OC-CDN deployments are just a start. Now the upstream CDNs – either owned by the Content Provider or available on commercial CDN services – need to implement the OC Controller component to complete the Open Caching ecosystem.
Early field tests for an Open Caching platform, reported by Verizon at NAB 2022, showed that QoE performance KPIs all improved over the base case – including start-up time, sustained bitrate, and peak bitrate. The SVA (Streaming Video Alliance) will soon release a report with more details.
These results align well with reports from leading D2C Streamers that are using Private CDNs deployed inside ISP networks. The improved results stem mostly from the placement of Edge Caches inside the ISP’s network, which improves performance by avoiding congestion with other internet traffic at peering points and inside ISP core networks.
But other factors can also drive performance improvements, such as the degree to which the Edge platform is managed to assure there is sufficient capacity to support 100% of the demand. For example, if capacity is allocated to a single Content Provider and the total platform is planned to provide sufficient excess capacity, then performance will be higher than on a multi-tenant platform without any excess capacity. Running “hot” against available capacity is always a risky strategy for high-performance, latency sensitive applications like live video streaming. Open Caching specifications provide ways for capacity to be understood before allocating traffic to an Open Caching Node (OCN), but if demand exceeds capacity overall, then QoE problems will persist.
Open Capacity Management
Performance is critical for Video Streaming. And as noted in part 1 of this article, performance is tied mostly to capacity availability. The Open Caching specification for Open Capacity Management is potentially its killer app.
Open Caching envisages global, democratized, unified CDN capacity. This is a grand vision of easily accessible streaming capacity for the world’s streaming video businesses that are looking towards a future where most content will be consumed via IP over fixed and mobile broadband networks, and at higher resolutions / bandwidths than today. In this vision the capacity usage interfaces and operations would be standardised by OC specifications. Also, capacity availability would be made visible through the same standard interfaces, allowing Content Providers to understand and buy capacity from any OC CDN supplier to meet their needs. In short, a dynamic map of global OC-CDN capacity could become visible by OC-CDNs being widely deployed. This idea would democratize access to CDN capacity and would simplify the technical operation of a multi-CDN platform that spans multiple ISPs to achieve audience reach.
This model could potentially be the key differentiator for Open Caching as Content Providers consider their CDN strategies. Today, larger Content Providers access CDN capacity through a range of relationships, often with multiple CDN providers, mostly direct with public CDN providers or via a CDN aggregator. Increasingly, private CDNs are being deployed or considered in RFIs and RFPs by larger Content Providers, like national broadcasters. Smaller Content Providers typically rely on an OVP (Online Video Platform) provider, that bundles CDN services into their content management and content origination services. Open Caching would introduce CDN services from the ISPs instead, although they would still need support from a range of established CDN service providers or CDN technology providers. If ISPs in a single country broadly deploy Open Caching platforms, then Content Providers with large national audiences would be able to consider those platforms for large percentages of their audiences.
So, can this work? Technically, yes, the specifications are emerging now. And as Jason Thibeault, SVA’s Executive Director states, “Open Caching is an overlay on existing CDN infrastructure, so it can exist as an option alongside other CDN services and technologies. The big difference is that in Open Caching, the Content Provider or their CDN operator can directly manage the Open Caching Nodes, which they are typically unable to do in a proprietary CDN environment.”
So, two large questions remain: 1) will ISPs implement Open Caching platforms and offer CDN services? and 2) does Open Caching result in a better set of commercial relationships for Content Providers with CDN suppliers? These questions will be explored in a following article about the commercial aspects of Open Caching, and what this means for broad industry adoption.
Larger Content Providers with regional, national and international audiences need to think about multi-CDN strategies, generally because no single supplier will have the right capacity to support all the demand. Therefore, the CDN selection capability is important to choose the best CDN to utilise based on a mix of price and performance parameters. In a multi-CDN environment that has an OC-CDN within it, the Request Router (RR) component will first select the CDN to deliver the content. Once the stream has moved inside that OC-CDN, the local RR component will select the Edge Cache for stream delivery to the client.
If there are two layers of CDN (e.g., a public CDN interfacing with an ISP OC-CDN), then the RR component of the first CDN layer (i.e., the public CDN) will select the ISP OC-CDN after understanding that it has available capacity and performance. Once selected, the ISP OC-CDN platform will own the stream and its future session management control. Within the ISP OC-CDN, the RR component will choose which specific OCN to serve the stream from. At that point, all communication between the Client and the CDN is between the Client and the OCN.
CDN selector tools, including those integrated with client-side analytics, would remain the overall controller of which CDNs serve which end customers. The Open Caching Request Router sits underneath a CDN selector in the decision-making hierarchy. It is therefore possible that an OC-CDN could be blacklisted for poor performance, like any other CDN. To be re-activated by the CDN selector, the OC-CDN would republish information about its available capacity and performance levels via the Footprint and Capabilities API, to demonstrate it is ready to receive new traffic.
Open Caching at its core is about interoperability for metadata, capacity management, location management, and logging, which today are managed by CDN’s proprietary algorithms. The rest of Open Caching is about HTTP routing, which is a standard approach deployed by each CDN using approaches that include eDNS0, DNS resolver, Anycast, and HTTP redirect.
Open Caching adds a fifth interoperability category of transparent stream management between multiple OC-CDNs. But as with any specification or standard, this does not mean a seamless integration between CDNs because specification implementations can vary. Real-world technical testing and ongoing alignment of specification implementation will be necessary across all suppliers of OC-CDNs for full interoperability.
CDNs deployed inside ISPs today that are already capable of operating with multiple types of Origins generally have the preliminary building blocks for implementing Open Caching. There are various ways to upgrade these CDNs to implement the Open Caching compliant software. Jaya Devabhaktuni, Architect at Velocix and a contributor to Open Caching specifications, states, “The approach to an upgrade depends on how each CDN vendor chooses to implement the OCC and OCN functions – they could be standalone software modules, plugins, or enhancements to existing control and data planes. The main points are that the control plane must support the OCC capabilities, and the data plane must implement the OCN capabilities. These OC capabilities could be deployed as an overlay on top of an existing Edge Cache, or they could be deployed on new standalone OC nodes within the network operator.”
Today, there are a range of CDN models that Content Providers can consider today, as shown in Figure 1.
Figure 1: Multi-CDN architecture including Public CDN, CP (Content Provider) Private CDN and Open Caching CDN, showing where OC Controllers (OCC) and OC Nodes (OCN) will be deployed.
The Public CDN connected directly to an ISP without any on-net CDN capacity has been the normal model for over a decade and continues to be the dominant model today for broadcasters’ D2C services. This appears likely to diverge to include one or more of the following 3 models based on the scaling up of the broadcasters’ streaming volumes.
The leading global streamers have driven the deployment of the CP Private CDN model, deployed at Internet Exchanges and often deep inside ISP networks. This previous article describes this model.
And as Content Provider apps are integrated into existing pay-TV services which already use an on-net CDN, some of the Content Provider traffic traverses the ISPs’ existing proprietary CDNs.
After 8 years, Open Caching is bringing a new model into the mix, which we see today primarily in the form of point-to-point solutions between Content Providers supporting Open Caching and some ISPs that are deploying OC-CDNs. The full vision of all public/private CDNs and all ISPs deploying OC-compliant CDNs is still a long-term vision for now, and indeed the path to achieve the full vision is not yet clear given the various stakeholders with different commercial interests.
So, for now, the future contains a mix of CDN models. But will the future of D2C streaming in a multi-CDN architecture be simplified because of Open Caching? Technically it should be, but it depends most heavily on the commercial and deployment realities. The technical vision is close to reality after 8 years of specification-writing effort. It is not clear how long it will take to achieve the full operational and commercial vision of an open caching environment, but momentum appears to be building.
You might also like...
While the business side of streaming has a host of terms that can confuse, the same can be said of the technology side. Sometimes the confusion stems from a lack of definition or an overuse of a term from so…
A discussion of camera sources, contribution network and remote control infrastructure required at the venue.
It was ten years ago, in the fall of 2012, that NBCUniversal opened a new international broadcast center in Stamford Connecticut, as the home for NBC Sports. It served as a way to consolidate its growing employee base and the production…
Imagine supports media companies’ bottom line with “converged” technology platform.
A discussion of how to create reliable, secure, high-bandwidth connectivity between multiple remote locations, your remote production hub, and distributed production teams.