Webway Sigalerts--And How To Unsnarl Them.

Part 2: The Keynote Conference speeds up solutions

This article is the second in a two part series. The first part appeared in the October issue of CTR.

One of the most enlightening presentations at the Keynote Conference was delivered by Peter Sevcik, president of NetForecast, regarding performance-based ROI analysis: how to measure the ROI of the various solutions to Internet performance problems. The talk concentrated on one particular solution, the content delivery network (CDN), which distributes static or slowly-changing content to caches at the "edge" of the Internet-in the points-of-presence (POP) of major ISPs. Before noting his conclusions it's worth reviewing how a CDN works.

The CDN market is one of the most dynamic in the Internet space, represented by high-value, well-funded companies like Akamai, Adero, Digital Island (represented at the conference), and many others. The two fundamental insights that CDNs are founded on are actually quite simple. First, if you serve content from closer to a browser, that content will tend to display faster. Second, you can do this by exploiting the existing Domain Name System (DNS) that serves as the address directory for the Internet.

Closer is faster. By cutting down the hops from server to browser (the average packet travels through 17 routers!), you cut down light-speed latency, router latency (how long it takes the routing engine to choose a path), and the impact of congestion. CDNs do this either by co-locating their cache servers in the points of presence (POPs) of ISPs or by building a network of their own POPs served by a private network (or a portion of the Internet whose routing is carefully controlled-i.e. an overlay network such as that supplied by InterNAP), or both. This cuts the average number of hops from 17 down to a fraction of that: in the case of an ISP POP, none or one; in the case of a CDN data center, certainly less than five. The number of hops saved tends to be lower overseas than in the U.S. and Canada.

Of course, you can't accelerate all the elements of a web page. Remember that a web page is actually a set of files that are downloaded across individual TCP connections.

Only certain types of files and content are currently cacheable: static or slowly changing data and media: e.g. "brochureware," GIFs and other graphic elements, and non-interactive streaming media. The elements of a web page that comprise a personalized page (e.g. My Yahoo), transactions, applications, and secure communications cannot at this time be cached; some of these, especially secure transactions, may never be cached due to customer reluctance to surrender control of this content to a third party. Still, a large portion of a web page, especially if it's designed with edge delivery in mind, can be cached and therefore delivered faster. The rapid appearance of static content, which is likely to make up a large part of the "look and feel" of the web site, is enough to keep surfers engaged and willing to wait for the higher value, non-cacheable content.

Looking For A Domain

The Domain Name System is responsible, among other things, for resolving human-readable addresses like www.yourcompanyhere.com into machine-readable numeric addresses like 255.040.089.145. It's basically a machine-readable white pages for every node on the Internet. When a web site contracts with a CDN for its services, the first hit on the company web site does two things:

1. Use an HTML Redirect command to tell the browser to go to the CDN server (call it CDN.com) for all the static content that's been cached;

2. Begin downloading all the non-cached elements of the page and handle interactions with the user.

The browser then queries DNS for the location of CDN.com. The local DNS server (local to the browser) likely doesn't know and starts climbing the DNS hierarchy to find a name server that does. What it soon finds is a DNS server maintained by the CDN which does a little more than the usual DNS operation: it figures out where the local DNS server, originally queried by the browser, is geographically and returns the address of one of the CDN's network of cache servers that is closest to that DNS server and thus likely closest to the browser. This address percolates back to the browser which thenceforth goes to the CDN server for all redirected content. Meanwhile, of course, the original web server has been downloading any non-cached content.

Built For Speed

The result is an accelerated web page load time which tends to make visitors stick around longer. That translates into more completed transactions, more click-throughs, etc. It also lowers the capital investment required in the web site since a smaller number of servers are required to serve the same number of customers. Little wonder that this part of the Internet Infrastructure market is booming!

But Sevcik pointed out some of the dark linings to this silver cloud. CDN discovery via DNS takes time, and the closest server may not always be the best server; it may be busy or its content outdated. New content discovery and management protocols are under development to address these problems; however, don't expect rapid resolution. As with so many Internet standards, this area is being fought over by at least two powerful forces: Cisco Systems and a consortium composed of some of its bitterest competitors. For the time being, the proprietary solutions out there that have already addressed this problem will be the only way to go.

Sevick also noted that the last mile (from the ISP to the subscriber) can have a major impact on CDN performance: while on broadband the overwhelming probability is that delivery from the caching server will commence within a second, over dial-up it's more probable that the cached content will take up to 15 seconds--this from actual measurement. Nonetheless, given the tremendous scalability advantage a CDN confers on a web site by offloading static content to hundreds or thousands of edge cache servers, his analysis clearly showed how cost-effective a CDN can be for many web sites.

Hands On Delivery

Another strategy or product area he covered in his ROI analysis was that of traffic shapers such as those offered by Packeteer and Sitara. These devices act as an intelligent queue/cache for traffic to the Internet, giving priority to packets on the basis of the application concerned, the user, or other information that can be gained by packet inspection. While this doesn't directly address Internet congestion per se, it does assure that traffic with the most value to a business will get priority over other less time-sensitive material, such as email. They may also, as in the case of the Sitara QoSWorks device, offer a proprietary protocol to improve end-to-end communications between two such devices.

With or without this, Sevcik gave a case study of how such a device benefited an Application Service Provider who installed one on customer premises to give priority to the applications it was delivering to that customer over the Web. The device accelerated application performance by over 50% (while, of course, reducing the performance of non-critical traffic such as email, backup, and web browsing). The bottom line was a savings of $22,000/month in staff costs, a payback time of about six days, and, not least, proving the ASP as a viable business.

How Much For Insurance?

Along similar lines, Martin Marshall, an analyst at Zona Research presented an overview of web robustness measurements and derived a rule of thumb for how much to spend on them. Devices or services designed to tell you how well your web site is working can measure everything from Web-related problems (the emphasis of Keynote, the organizer of the conference) to the relative effectiveness of various subsystems in each server, and everything in between. (Down the road I'll look into these services and what they can do for a business web site.) Although I can't go into details in this limited space, Marshall recommended that sites spend 4.5% of transaction revenues on measuring the performance of their site.

Zona had recently surveyed a number of people responsible for web site operation to find out what their prime concerns were and how they were responding to them. The results were very interesting and are available from Zona as a report. What stood out for me was that besides getting talented staff (by far the hardest problem they face--no surprise), the difficulty of integrating e-commerce with their sales process (an internal, business problem) and navigation bottlenecks (an external, Internet problem) ranked as equal challenges, followed closely by inconsistent performance (which can be caused internally or externally). And the major performance concern? Again, no surprise: security software, followed by network bottlenecks-and so we're back to congestion again.

The bottom line is that there's a lot of money to be made in Internet performance, whether in integrating the web site hardware and software for the most efficient operation, improving its performance with additional hardware or software, or monitoring its performance.