In The Middle

The Internet: A Home Run Ballpark

Fans loved it. Baseball has never seen anything like it. One player, Brady Anderson of the Baltimore Orioles, who in his e ntire minor and major league career before this year hit fewer than 100 home runs, hit 50 this year! He was a leadoff batter. Leadoff batters aren't supposed to be hitting home runs; they're supposed to be getting on base. Yes, for baseball, this has been the year of the gopher ball. And it's been much the same on the Internet.

The Internet Home Run Derby You like the Internet because you can get anywhere from where you are. From home plate, you can go right out of the ballpark to the content you want to see, or so says your Internet service provider (ISP). From the networking perspective, these home page accesses are home runs. Everyone comes back to the one place on the Internet that has what he or she is looking for--and performance suffers.

We all gang up on the same popular site servers. And, if those servers ar en't slow, then it's the link to their servers from the Internet that is slow. In fact, our home runs exacerbate congestion on parts of the Net that might not have to be congested . They ruin the old 80/20 rule. Instead of only 20 percent of traffic traversing the backbone, on the Internet it seems all the traffic traverses the backbone.

Or, it's the fact that there are just so many hops between you and the page location. The last time I measured using IP Trace, it took nearly 10 hops from my dial-in ISP's point of presence (POP) in Houston to Netscape's servers in Silicon Valley. That's a lot more than the four bases that make up a home run in baseball. Plus, you have the same path back. No wonder latency-adverse applications have trouble on the Internet. They have so much weight that they'll never be able to negotiate all those bases.

Unfortunately, this home run capability is built in: URLs only point to the original location of the Hypertext Markup Language (HTML) page that needs to be loaded. Without next-generation name services or even more serious directory services for pages, any kind of load-balancing across multiple copies of the same content is not realistically possi ble, and certainly not with geographic diversity. After all, who's supposed to decide which path is closer to the possible multiple locations of a given home page? Actually, Cisco's forthcoming Distributed Director is supposed to measure this at the network level (hey, routers are supposed to know this kind of stuff), but we'll have to see how popular this option becomes.

In the meantime, what do you do? I think it's time for a good defense, and a better offense.

The main line of defense against home runs in the Web world is the Hypertext Transport Protocol (HTTP) proxy service. Typically implemented in a firewall between users and the WAN link to the ISP, these software servers will cache any pages downloaded through them. After the first home run through the network, a given page should be located locally in the proxy server's di sk cache. No more home runs.

At least, that's the way it's supposed to work. Unfortunately, caches fill up with data and start dropping older pages. Data that might be imp ortant to a corporation might get displaced by less critical information. After this caching out, another home run will be required. Such proxies are automatic, yet this simplicity is actually what keeps them from being proactive in preloading data that users might need on an ongoing basis. Surely, over time, we'll see more intelligent caching agents that truly begin to anticipate (based on history) user data needs.

Proxy Defense Indeed, Microsoft is claiming its new proxy service can track usage patterns automatically and begin to auto-pull pages proactively from commonly accessed sites (yes, I'm referring to that product code-named Catapult that has been waffling on target functionality for some time but is now due by year's end). Netscape has added page copy scripting support to its proxy server, but it sounds rudimentary. Still, it's nice to see such services getting more intelligent.

Proxy services, however, can't cache data that's not in HTML pages. As data moves off static HTML pages and into back-end resource servers such as relational database management systems (RDBMSes), Notes databases and Exchange schedule services, there's no static data to cache. It's all interactive, and the server being accessed is still a distant home run away. Long term, caching may not be adequate to serve as a pull-once (over WAN links), pull-many (over LAN connections) paradigm.

Caching works where users are funneled through the proxy service--something usually enforceable for users crossing the secure corporate firewall boundary to see the wide world of the Internet. If they don't go through the proxy service, such users won't get out at all. This, however, doesn't help average ISP-connected end users who don't even know if their ISP has a proxy service (not for access control but primarily for local caching), what its address might be or h ow to configure the browser to access one.