A 'C change' in CDN?

Telcos worldwide are looking hard at the CDN opportunity

In the world of content distribution networks, A is for Akamai. What about the rest? Is B for BitGravity, or maybe BitTorrent because of the potential impact of peer-to-peer technology on CDNs? Is C for content? I don't think so. I think it's for carrier or maybe cloud -- and in either case, the "C change" is potentially a major one for the CDN world.

Content distribution networks evolved as a means of getting traffic off the Internet backbone, where peering delay and the intricacies of peering agreements threaten to make any highly visual Web site (much less content) into a PR nightmare for the owner. A CDN acts as a local cache for key content elements; with a local cache, elements load faster and use less core bandwidth. The process works best if there's a lot of repetitive demand for a relatively contained list of content and the content in demand isn't available locally through some other means. The reason a P2P network could affect CDNs is that it offers another local place where content might be available.

P2P technology probably isn't much of a risk to CDNs, however, because there's no assurance that P2P-streamed content would be of the quality that site owners want. What would create a bigger threat is a metro content-storage alternative from a credible provider with high performance and volumes of storage. That is exactly what telco TV, telco CDNs, and telco cloud computing are threatening to provide -- and soon.

If you think about it, anything that hosts storage, content, computing or applications can be considered a form of cloud computing because it provides a network-addressable resource. A big data center in a metro area used to support video on demand for a cable company or telco would serve just fine as a storage point for other content, including the stuff that's hosted on CDNs. Not only that, it probably would offer pretty good performance and economies of scale in content storage and delivery.

That may be why AT&T has announced its own CDN plans, and why other telcos worldwide also are looking hard at the CDN opportunity. If you have to build data centers, storage farms and fat connections between them and your metro network, you may as well sell some services from the new infrastructure you've built and get into the CDN business. Nevertheless, costs aren't the only reason some of the big telcos and cable companies are looking at rolling out their own CDNs. There are some new issues in the CDN world these operators believe need special attention.

One big issue is the handling of interactivity. In the old days, content served from CDNs was static: You pushed it out when it was called for, and you forgot it. With highly interactive pages and with more complex video, there is some need to support interactivity to make it possible to support Web 2.0-style dialog or to pause and play, rewind, or fast-forward video content. Interactivity also may be needed to allow for selection and insertion of ads based on the viewer's demographics.

Page Break

The problem with interactivity lies in with whom the user is interacting. If the content is served from a CDN, where does the interaction go? Back to the content owner? It doesn't know the context of the interaction. To the CDN? The more interactivity is required for Web-site control or video delivery, the more the serving of the content from a CDN starts to look like just moving the whole host process to every metro area. That, of course, is likely to run up costs. Of course, if you're a telco or cable company that wants to serve IP-based video on demand to customers anyway, it makes sense to use the same tools to provide interactivity to CDN-hosted videos. In fact, that could be a valuable differentiator.

Another issue is that of "operationalization." The Internet traditionally has been a best-efforts network, and so CDN performance traditionally also is best-efforts. In fact, for a given video experience, it would be difficult to tell just what piece of the delivery infrastructure created a perceived problem with quality. For telcos, video probably will be a premium service with performance guarantees. If you're a telco who stays awake at night worrying about how to support millions of premium video customers, who might call with complaints, you don't want to build that service from pieces that don't have telco-compatible management interfaces and alert-handling. Standards bodies are working on the management of complex experiences made up of content, network resources and even hosted applications; but CDN players aren't part of the groups involved. The telcos are; and by pulling CDN functions into their own infrastructure, they can get quicker solutions to operations problems.

None of this is going to cause the death of CDNs. The original mission of CDNs, in fact, is probably as essential as ever -- or more so. The challenge is that these changes could create pressure on prices for CDN services as the telcos enter the market, and the interactivity and operations requirements could force CDN players to deploy new equipment that would raise their costs.

On the positive side, the changes the telcos want could create opportunities for new services and for differentiating the CDN incumbents. If CDNs advance far enough, it probably would discourage at least some of the telcos from getting into the space at all. But there's little chance that big changes aren't in store for CDNs, and anyone who thinks otherwise is probably in D -- for denial.