Pending Protocol Promises ISP Revenue Opportunities

The Internet Content Adaptation Protocol (iCAP), now a draft submission to the IETF, will enable ISPs to run locally targeted ads. It will also enable ISPs to offer virus scanning and other revenue-generating application services.

Lisa Phifer
VP Core Competence, Inc.

ISPs deploy web caches to distribute content to the network edge, improving the customer experience and reducing backbone network traffic. The Internet Content Adaptation Protocol (iCAP) hopes to leverage these edge devices as a foundation for realizing new ISP revenue opportunities: value-added services that tweak web content to:

• eliminate viruses
• fit PDA and cellphone screens
• insert targeted ads
• speak the user's local language

iCAP is the brainchild of the iCAP Forum, an open consortium of edge device and application service vendors formed last December by co-hosts Akamai Technologies and Network Appliance.

According to Kieran Taylor, Product Manager at Akamai, in just three months, the Forum has grown to 70 members, representing a solid cross-section of the affected market segments. Members now include AdForce, Advertising.com, BroadVision, Cobalt, Compaq, DoubleClick, Entera, Finjan, iKnowledge, InfoLibria, Lionbridge, Navisite, Network Associates, Novell, N2H2, Predictive Networks, Secure Computing, SightPath, Symantec, Trend Micro, and WebSense — and the list goes on. Perhaps the only segment with light representation right now is wireless.

This week, the Forum announced completion of a first draft protocol for submission to the IETF Web Replication and Caching working group. "The iCAP Forum was formed to meet time-to-market needs by quickly producing an initial specification," says Taylor. "It will now be up to the IETF to refine that spec into an industry standard." The Forum will continue to serve as a proving ground for iCAP proof-of-concept services, helping to work out implementation issues.

A Universal, Distributed Approach To Content Adaptation
Content adaptation, even at the network edge, isn't really a new concept. Distributed load balancers can redirect requests based on geography to an origin server that provides regionalized content.

On-board content filtering services can be added to most caches today. Wireless network proxies transform both protocol and web content, converting HTML into WML for small-screen display and HTTP into WDP for wireless delivery. Some proxy firewalls use a content vector protocol to forward HTML to a scan server which detects and strips viruses.

But these point solutions lack a unifying architecture and single, simple protocol that enables efficient distributed processing for any web service needing content adaptation. Complex, narrowly-defined, or proprietary vector protocols don't facilitate rapid deployment of new services. Monolithic servers that host embedded services don't scale well — in most cases, it makes good sense to offload adaptation. According to Taylor, "Edge delivery devices have traditionally been best-of-breed appliances designed to move bits quickly, not to make application decisions. With iCAP, edge devices can interface with gateways that are designed to make application decisions."

And, when appropriate, iCAP-enabled caches can store modified content so that adaptation needn't be repeated over and over again.

How iCAP Works
iCAP is an HTTP-based "remote procedure call" protocol that allows an edge device like a cache to forward HTTP messages to an application server for transformation or other processing. There are three ways in which iCAP can work.

• Request Modification: Suppose a web cache receives a browser request. With iCAP, the cache can send the request to a content filtering server. If the request passes the filter, the server returns an OK response, no adaptation is required, and the cache continues normal request processing. If the request is denied, the server modifies the request to point to an error page, and the cache serves the error page to the browser.
• Request Satisfaction: Consider the same example: a cache receives a browser HTTP request and sends it to a content filtering server. But in this case, the content filtering server actually carries out the request: it retrieves the requested page or error page, returning the HTTP response to the cache for storage and relay to the browser.
• Response Modification: Here let's illustrate another iCAP-enabled service: anti-virus scanning. Upon receiving an HTTP response, the cache sends embedded objects that can carry viruses to a scan server. The scan server checks and, if necessary, disinfects the objects before returning them in a modified response to the cache.

In each case, the iCAP client and server exchange standard HTTP GET and POST requests and responses. According to Ed Chow, Manager of NetCache Marketing for Network Appliance, "iCAP is simple and fast to implement. Content is vectored by HTTP POST, with results returned by HTTP as well. This model lets the application run virtually as-is — all you need is an iCAP handler that strips objects from the HTTP POST and submits them to the application."

While iCAP makes it possible to offload application processing, distribution may not always be warranted. "Performance-sensitive services may remain on the cache," says Chow. "Filtering requires examination of all objects. But anti-virus scanning requires only a subset of objects, lending itself to offloading. Applications associated with real-time services like streaming media may remain on the cache so that we can optimize delivery."

goto Page 2: Using iCAP to Create New ISP Revenue Opportunities