Network Computingwww.networkcomputing.com

My solution after years of commuting: First, move to another city. Second, get a job close to where I live. I'll admit, Houston's got some bad traffic (a never-ending jam near the biggest mall in town, and increasing problems outside of town as bedroom communities expand faster than road systems), but L.A. takes the prize.

Planning Traffic on the Network Highway Now, imagine you're the city planner facing rapidly increasing auto congestion. How do you ensure that ambulances can get through? The president? What about heavy freight? And don't forget about taxpaying individuals, and more especially, corporations fleeing rising congestion.

You don't really have to work that hard to understand the city traffic planner's problems, do you? You and your network are facing the same problems every day.

Most users I talk to quickly note that their networks are falling behind application bandwi dth requirements. Well, actually this is usually after they've ruefully commented that it's difficult to even determine application bandwidth requirements until it's too late (see "Preventing Application Nightmares," October 1, page 149). No matter how much bandwidth is planned, procured, installed and paid for, applications somehow could use more.

This problem affects campus and LAN backbone networks, resulting in the craze over switching infrastructures and ATM. It affects Internet connections, resulting in swelling interest in HTTP proxy caching servers and rapidly increasing line bandwidths and costs. But, nowhere is the bite of too little bandwidth felt as painfully as it is than by users in larger WAN environments. When you have 100 or 1,000 branch sites, simply "adding bandwidth" can escalate costs beyond the break-even point.

Similarly, international links for global corporations are extremely costly to upgrade. Sometimes you can't buy bandwidth, even if you could pay for it--businesses that need offices outside major metropolitan areas can be stuck looking for WAN link options. For such larger scale WANs, buying bandwidth is simply impossible.

Your only choice is to make applications smarter about using the available bandwidth. Unfortunately, despite all the negative examples and possible alternatives (a.k.a. Band-Aids) that I've found, problems will still persist. There will always be "bad" applications, and too many of them to keep expensive WAN links from being oversubscribed.

Shaping Traffic A novel approach to helping applications function better over congested links is to differentiate them and somehow prioritize important ones. Solutions must monitor more than a device- or link-specific utilization level; they must characterize utilization by application type or server connection to enable you to pinpoint problems by applicatio n.

Then, if you can't guarantee that all traffic can get there in time (you can't buy enough bandwidth; congestion and oversubscription is a reality), at least make sure the important stuff is delivered. I think the toll-road analogy works for networks: If there's an application that is mission-critical, make sure it gets what it needs. After all, it does pay the bills. Make Internet browsing or file transfers a lower priority, thereby, issuing them slower performance.