Location, Location, Location

ENT, March 26, 2001 by Mark McFadden

No, this isn't a column about real estate. This is about your content and applications.

Not long ago, large Internet services and companies with substantial content to share on the Internet struggled to avoid the problem of being far from the Internet's backbone. By buying a location closer to the backbone -- using a hosting facility that was near an Internet exchange point or large service provider that had significant peering relationships with the telecommunications providers that dominate the Internet transit business -- companies avoided the extra router hops that contribute to a Internet visitor's perceived delay.

It's an expensive proposition, and it doesn't always work. No matter how close your servers are to the core of the Internet, a remote visitor always has to be routed through the distant byways of dial-up ISPs. While you may be able to control where your servers are, you can seldom control how your visitors, clients, and remote employees connect.

For companies that distribute large amounts of information, there was always the possibility of multicast: the effort to wire the Internet's routers and switches so information could be "broadcast" rather than requiring a server to set up a vast number of simultaneous one-to-one connections. Multicast works well for a very specific class of private Internet applications, but it seems that it will never show up on our public net work. What are we to do?

Enterprise Internet applications struggled with this dilemma until recently. Lately, large Internet-content companies have discovered an old business adage: If our customers are having trouble coming to get our product, what happens if we bring the product to them? That's just what large Internet presences like Microsoft, Yahoo, and MSNBC are doing.

It's called content distribution.

The idea is simple. Build an infrastructure on the public Internet that efficiently directs and distributes content and applications from "home servers" to the edges of the Internet, then allow different businesses to exchange money for the content distribution services. Neither your company nor Yahoo is interested in building a new network that would ensure high-quality, end-to-end networking for static, dynamic, and streaming content. Instead, pay to have the content hosted in an enormous variety of places on the Internet, as close to the visitor as possible.

In fact, these new content-delivery. networks provide more than simple hosting of applications and information. After providing a closer source for the content, these new networks then provide mechanisms for measuring content traffic patterns and load balancing, and reports back to the upstream network providers and content companies.

I think one surprising consumer of content delivery networks will be enterprises. Large corporations want outstanding quality of service for their employees and customers. They seem willing to open their pocket-books and use new content-delivery strategies from both the producer and consumer viewpoints.

The companies Inktomi and Akamai are leaders in this new industry. Both are pushing the envelope on content delivery, even making it possible to distribute streaming content throughout the Internet. Their services are improving the speed and reliability of the Internet by making multiple copies of important content available throughout the Net. This is one of the most important advancements for developers to emerge in years. But I see two clouds on the horizon.

First, the youth of the content-delivery solutions means nobody has had time to define how an enterprise's applications are supposed to talk to content-delivery applications. I'd like an enterprise's applications -- not just its users -- to benefit from the performance and reliability of these new content services. Unfortunately, with the proprietary nature of the new systems, there's no common way to build applications that can reliably talk to content delivery networks.

Second, there are no Internet standards that allow the content delivery systems to talk to each other. Interoperability, the touchstone of the Internet, is yet to be achieved for these services. Fortunately, an industry consortium is trying to address these problems. A proposed protocol, ICAP (Internet Content Adaptation Protocol), has been proposed, and a working group at the IETF was formed to build a vendor-neutral content delivery standard.

It's a technology to watch because it may spawn a new generation of services customized to "local" requirements, such as pages translated to the local language or anti-virus checking on the fly. A technology that improves the performance and reliability of the Internet -- as well as enabling entirely new services--is a technology to watch.--Mark

McFadden is a consultant and is communications director for the Commercial Internet eXchange (Washington). Contact him at mcfadden@cix.org.