2012-06-05 17:51:39 | content provider CDN

Content Publishers CDN

Today, Netflix announced OpenConnect, a way for Internet Access providers to extend Netflix own CDN: http://blog.netflix.com/2012/06/announcing-netflix-open-connect-network.html

(For some reason Netflix geo blocked the OpenConnect website for non US viewers. For non-US citizens, I was pointed to download these documents: OpenConnect Webpage (PDF) OpenConnect Deployment Guide (PDF).)

This approach is very much in line with the trend that Jet-Stream predicted: Content Publishers want to be in full control of their workflow chain, right down to delivery. 

Next to telco CDNs, publisher CDNs are yet another potential threat to Internet CDNs whose best effort infrastructure simply does not live up to the expectations and requirements from premium content providers. 

Maybe even a bigger threat since this is a massive signal to the CDN industry that content publishers are not just technically able but also have the strategy to directly work with access providers. This is their customers saying: let's cut out the man in the middle.

In our view, Internet CDNs are not a good fit for both premium content providers nor for telcos. Internet CDNs cannot go beyond best effort delivery since they don't own the pipes to the end user, they don't use managed technologies for request routing and distribution. They can't offer any serious SLA about delivery capacity, delivery guarantee, and delivery performance. They cannot offer an end to end service level.

So it makes a lot of sense to bypass Internet CDNs. However, we have seen multiple attempts of content publishers trying to deploy and control edge servers within telco networks. And in general telcos don't like that. They want full control over the delivery nodes. But more importantly, also control over the traffic patterns in their network. And even more importantly, control over the associated costs.

That is why most telcos prefer to operate their own CDN and let content publishers federate from their private CDNs to the telco CDNs. This way, the content publisher gets full end to end control over delivery, but the telco gets full control over the infrastructure and the costs. That is the best win-win scenario, not just for the content publisher and the telco, but also for the subscriber.

However some thoughts:

- Are telecom operators willing to allow Netflix to reach deeper into their network? Telecom operators have already made the mistake in the past to let Internet CDNs deploy servers in their network. We see a clear trend of large telcos kicking all CDNs out of their network. Because they see Internet CDNs, but also Google servers as a trojan horse. Will telcos accept that next to Netflix other content providers will deploy or demand edge server resources in their own networks? We don't think so. Maybe in the U.S. because it is a totally different market than in the rest of the world.

- Be warned for the trojan horse of edge servers. Internet CDNs and Internet content providers try to get telcos addicted to hosted edge servers in their networks. The short term benefit is lower peering costs. Once they are in, they keep extending and extending their footprint. And then they can turn on the telcos and dominate the traffic flows and the business. Leaving the telco to be a commodity access pipe to content, without any means for investing in their infrastructure and without any control over delivery, distribution and traffic flows.

- As a telco you end up having to host racks for Microsoft, Hulu, Google, Apple, Amazon, Netflix, and all those other content providers out there. Who's paying? And where is the efficiency? this model doesn't let the telco optimize server resources between these CSPs. Shouldn't the content providers pay for the provided rackspace, power, cooling, operation and traffic on the telco networks?

- The Netflix CDN edge is actually just a basic caching system built around NGINX (we love NGINX by the way). If the telcos have to pay for all the above anyway, why wouldn't they just run NGINX as a transparent cache in their network? Same costs, but with the benefit of being able to cache all inbound traffic instead of just Netflix. I know that CSPs hate their content being cached because then they lose complete control over the delivery. But Netflix is now risking that telcos go for a worse alternative.

- We have seen many telcos and content service providers try to develop their own CDN but most of them have already stopped their project after having invested too much money and time into a product that does not really bring what a proven, commercial CDN can do in terms of management, monitoring, performance, robustness, features and efficiency. The Netflix CDN heavily relies on too basic CDN technologies so they cannot enable a true end to end SLA and proper QoS (See this blog post and white paper). Netflix could have worked with the telcos and vendors to address that cricital issue! That is a missed opportunity. Netflix had a window of opportunity to bring online video delivery to a next level. Instead of working directly with the telcos on QoS, managed delivery, performance guarantees, capacity guarantees and SLAs, they opted for a basic best effort delivery solution. They risk that mass audiences walk away from the service because it cannot live up to the expectations of true HD digital broadcasting. Consumers don't expect a YouTube grade service on their computer but a full quality service on their smart TVs because they pay hard earned money for a service that is supposed to be a real alternative to digital HD broadcasting. But it isn't:

Internet grade CDNBroadcast grade CDN
99% uptime (best effort)99.999% uptime guaranteed
No delivery guaranteeDelivery guarantee
No quality guarantee (QoE)Always full HD quality guarantee
No capacity guarantee (shared Internet)Guaranteed number of concurrent viewers

The CDN Spectrum

The days that there were a few Internet CDNs are clearly over. There are so many models available, both for telcos and for content service providers. Below is our CDN spectrum list. From Internet CDNs to virtual CDNs, from Telco CDNs to Content Provider CDNs and all hybrid forms between them: 

Generic Internet CDN: Internet CDNs don't specifically focus on premium video delivery. They either run on the best effort Internet or use a private network. But they cannot deliver beyond best effort because they don't own the infrastructure and have no end to end SLAs with telcos. We see a trend where telcos kick Internet CDN edge nodes out of their network and renegotiate pricing for inbound traffic to be able to finance the costs generated by these CDNs drive who litterally dump more and more traffic into the telco networks.

Premium Internet CDN: StreamZilla: similar model to Internet CDNs, however using an advanced private network and managed CDN core technologies to guarantee a better service than generic CDNs. Very popular service since an Internet CDN is todays default way for CSPs to deliver their content on the web and mobile. Jet-Stream has operated this CDN service since 2004 and it is and always has been a very successfull business opposed to virtually all Internet CDNs who cannot seem to be able to monetize their service, especially not for video. 

Extended CDN: Many CDNs are not really capable of actually deploying a CDN in a telco network that can fully be managed by the telco. Therefore they extend their CDN into the telco network by deploying only their edge nodes into the telcos network as a trojan horse and sell it as a managed or as a wholesale whitelabel reselling solution. And then they call the traffic flowing between these edges CDN federated traffic. Which it is not.

Hosted private CDN: This model is a fully deployed CDN, hosted, managed and operated by the CDN operator, on behalf of a content service provider or a telecom operator. The hosted private CDN is a great model for content owners who wish to control delivery, but wants to outsource the entire operation. (Jet-Stream runs various hosted private CDNs for both premium content publishers and telecom operators.)

Simple CDN overlay: usually a third party overlay service, used by CSPs to load balance over multiple Internet CDNs. Will be used less and less because CSPs move to private or virtual CDNs. Some vendors call this CDN federation but it is not. (Jet-Stream does not support this model since it relies on basic DNS and caching based delivery which is substandard for our demanding content clients. )

Internet Content Service Provider CDN: fully controlled and operated by the CSP, including managed edge nodes as close to telco networks, spanning the Internet (globally or in a specific market). A trend in the CSP world, and getting more traction. Some CSPs have tried to build their own CDN from scratch which turned into a very expensive operation. So they now license technologies from CDN vendors. The problem with this model is that although this option gives the CSP more control, it does not offer any better SLAs or QoS than using regular Internet CDNs. (Jet-Stream deployed various CDNs for CSPs in the past which outperform regular CDNs). 

Extended Content Service Provider CDN: fully controlled and operated by the CSP, including managed edge nodes embedded within multiple telco networks (globally or in a specific market). A trend in the CSP world, and getting more traction. However telcos object to the idea of allowing third party edge nodes into their network: their trend is the opposite: kick out all the third party edge nodes from both Internet CDNs and content providers. This model is the predecessor of upcoming true CDN federation technologies. (Jet-Stream has been involved in multiple projects that operated for years with production traffic for live radio, live television and live broadcasts of major pop and sports events for many years.)

Virtual Content Service Provider CDN: the management part of the CDN is fully controlled and operated by the CSP, but the edge nodes are deployed and operated by the telcos. (globally or in a specific market). A new model that requires more advanced CDN technologies. A very cost efficient way of using CDN resources. It is a win-win model for both the CSP and the access providers: they both own and control their own part of the value chain and can arrange SLAs. This model is preferred to all above models, especially as long as true CDN federation is not really available on the market. 

Federated Content Service Provider CDN: a CSP operated CDN, offloading traffic through true federation into telco operated and controlled CDNs (globally or in a specific market). Unfortunataly the standards for true CDN interconnection and federation are nowhere near complete. Not a single vendor has true CDN federation implemented even though their marketing may make you believe so. (Jet-Stream was the first vendor to propose and actively manage CDN federation projects since 2002 and is heavily committed to bringing CDN federation to higher standards.)

Managed CDN for telcos: Please do not mistake this model with an extended Internet CDN. A proper managed CDN means that the vendor helps the telco to deploy the full CDN embedded within the telco network and manage it on the telcos behalf. (Jet-Stream has wide experience with this model, managing and supporting several CDNs for our telco, hosting provider and cable operators.)

Licensed CDN for telcos: More and more telcos - wired and mobile - realize that they cannot build their own CDN but still need a CDN. Not just to offload traffic in their network. Not just for a wholesale service to serve companies like Netflix. But also to enable their all-screens retail strategy. The telcos want to fully control the resources, platforms, edge servers and traffic flows in their network. A proper CDN enables this. And in combination with virtual CSP CDNs and CDN federation, this is the real killer combination. (Jet-Streams' sweet spot: we deployed more CDNs for telcos than any other vendor. CDNs running on a managed network, CDNs with premium delivery and request routing technologies: guaranteeing end to end SLAs in the entire value chain.)