I’m just going to come out and say it from the start—Open Caching is probably not what you think it is.
If you Google “What Is Open Caching”, you will get a lot of definitions that describe it as a way for network operators (ISPs) to build out their own CDNs. But, let’s be honest, operators could always do that because the pieces have always been available. Heck, even Comcast open-sourced their CDN software (Traffic Control) ensuring that any operator, with a bit of engineering resources, could deploy that software along with widely available reverse proxies and have themselves a CDN. But while CDNs, which are built on foundational standards such as HTTP and DNS, can be deployed fairly easily (and yes, there is a huge distinction between deploying a CDN and operating one), there is no standard for how they are configured to serve traffic. They are simply a collection of reverse proxies (caches) set in hierarchies and managed by a control plane (some sort of CDN NOC software).
Okay, so then Open Caching could be described in that way. And it’s obvious why the existing definitions would be skewed in that way—they are all vendor descriptions. Those vendors have created proprietary Open Caching boxes that they can sell to operator networks. The existing definitions, then, support the vendor’s use case.
But it’s not how I define Open Caching.
Why Open Caching
The SVTA (fka the SVA) began in 2014 driven by the idea of Open Caching. But OC wasn’t new. It was an extension of the IETF’s CDNi (Content Delivery Interconnect) work. Unfortunately, CDNi work had slowed down immensely. OC picked that work up and expanded it significantly. The idea was to not only enable content delivery networks to “interconnect” (through APIs) but also to fill out the many missing pieces needed for delivery network interoperability.
A True Need for CDN Interoperability
As the streaming industry has matured to multi-CDN strategies, it has become increasingly problematic that there is not a standard way to access certain CDN features such as logging, purging, configuration, and capacity notifications (which doesn’t exist at all). This means that streaming operators must create bespoke middleware implementations to programmatically control their delivery networks.
But streaming operators are always looking for ways to create more efficiency in their workflows and, more importantly, save cost. Building and operationalizing complex business logic to manage multiple networks isn’t the way to do that.
Open Caching, though, can provide the way. If CDNs were all “Open Caching Compliant” (meaning they make their caches available to Open Caching Network control planes via the APi specifications) then streaming operators could see their entire delivery architecture, comprised of multiple CDNs, as a single network. They could send purge requests across all networks simultaneously. They could pull all logs into a data lake using a single API call. They could get real-time capacity details across the entire network.
Proposing A New Open Caching Definition
Rather than this:
Open Caching is a standardized technology designed to enhance the efficiency of streaming content delivery by incorporating content caches directly within Internet Service Provider (ISP) networks (Qwilt).
How about this:
Open Caching is a delivery network virtual overlay, providing standards upon which a control plane can be built to manage a heterogenous delivery architecture using standard APIs which provide interaction, management, and announcement of content delivery services at different networks.
While Open Caching could enable an ISP to spin up their own CDN, an ISP doesn’t need Open Caching specifications to do so. They can just grab their own reverse proxies and do it. They could work with a partner, like Akamai or Varnish, to do it.
Open Caching is a way for the industry to standardize the way that companies which use multiple content delivery networks communicate and manage those delivery networks. Looking at Open Caching in this manner emphasizes the operational value to streaming operators like FOX or Peacock or Hulu rather than focusing on what the ISP can do with Open Caching. Of course, if an ISP deploys edge caches (perhaps with Varnish or NGINX) and ensures that those caches are Open Caching compliant, then their caching resources can be part of a streaming operator’s Open Caching Network. This acts as a virtual overlay to all of the CDNs they are using, announcing capacity availability in real-time, and, potentially, monetizing some delivery (although Open Caching doesn’t address the business side of things at all which is important).
A Note About Caches At the ISP Edge
Yes, ISPs want and need edge caches. Why? Because more caching at the edge reduces middle-mile back haul. It also increases viewer QoE. But caching at the edge can also be a new revenue stream for ISPs. We’ve seen a number of operators, like Orange, Verizon, Comcast, and Telefonica, announce commercial CDNs.
Again, though, this is not dependent upon, nor enabled by, Open Caching at all. Open Caching is not a reverse proxy like Varnish or NGINX or Squid. It’s not a content delivery network nor is it content delivery software. It’s a virtualized overlay network that is made possible by those APIs and facilitates a single management interface across those different networks.
Open Caching is not the edge cache. It connects the edge cache to an Open Caching Network that a streaming operator may have set up to help themselves better manage and deliver traffic across multiple CDNs (including those in operator networks).
Open Caching Today (And Tomorrow)
Today, Open Caching is a very robust Working Group in the SVTA. With multiple sub-groups and projects on-going, the Open Caching WG is actively submitting work into CDNi, ensuring that there is continuity across the two organizations, SVTA and IETF.
But what we need to get away from is this idea that Open Caching’s primary objective is to serve as a means for ISPs to create their own CDNs (and ultimately disenfranchise commercial CDNs). Open Caching is an enabling set of standards that allows anyone to stand up a CDN and have it interchange traffic and data with other entities. Open Caching then is a means to connect networks together, to give streaming operators (the companies that consume content delivery services, which can also be the ISP) a better and more efficient way to manage their use of different CDNs. And more efficiency means less complexity (which translates to less chance of problems) which ultimately means saving money.
And who doesn’t want to save money?
Open Caching will continue to evolve and grow. There are new initiatives, like Open Casting, that help integrate multicast into Open Caching Networks as well as Edge Storage that extends Open Caching into the home (so that streaming operators can better pre-position content in non-peak hours, for example). But for it to be successful, we must, as an industry, shake off the existing definitions that Open Caching is somehow related to ISP CDNs. While there is a connection, there is not a dependency. Open Caching is about codifying CDNi, about making sure that there is a standard way to interface and interact with content delivery services across any CDN.
Jason Thibeault
Jason is the CEO of the Streaming Video Technology Alliance, the international technical association for streaming video which brings companies from across the streaming ecosystem together to collaborate on technical solutions to delivering high-quality video at scale. In this role, he runs day-to-day operations, finances, member recruitment, strategy, and evangelizes the organization at events around the world. He is also the co-founder of a big data startup, datazoom.io. Jason is a contributing editor at Streaming Media Magazine and has written several books.