Traffic Shaping: Assuring Application Performance

Unfortunately, RSVP (Resource Reservation Protocol) and other explicit application request approaches are not mature enough yet. Likewise, many implemented network devices--such as routers and switches--are not ready to honor those requests if they were tendered.

So, while you're waiting for the full end-to-end QoS (quality of service) technology and policy management solutions to settle down over the next two to three years, you might want to look at a few intermediate approaches: router prioritization and traffic shaping. They are implicit QoS options (you can set them up without requiring applications or even end-node clients and servers to do anything). They just might keep important applications going for a while longer on existing links.

Router Prioritization Options Since you already own routers, look first at router prioritization. Most routers will prioritize traffic either by source or destination addresses or, even better, by TCP port numbers (to correspond with par ticular applications). Managing the many routers to keep these mappings consistent is difficult, but vendors like Cisco Systems (with its NetSys management products) are working toward more centralized and manageable configurations.

With router prioritization, traffic determined to be high priority (tn3270 traffic, SAP R/3 traffic, or two-tier client/server remote data access middleware applications) can be pushed through the router or switch quicker than other traffic, such as less interactive but burstier and larger FTP, HTTP and e-mail. This lower-priority traffic will be queued (using different vendor techniques, like Cisco's Fair Weighted Queuing). At some point, if queued traffic isn't forwarded, it will be dropped, forcing TCP or applications to try delivering again.

Traffic Shaping Approaches Next, loo k at a new set of nonrouter products that implement traffic shaping. These boxes go between a WAN router and the internal LAN link, and typically offer a fault-tolerant pass-through o ption that gracefully takes their shaping capabilities out of the path of traffic if problems occur.

Many vendors in this space queue up traffic just like routers, but they'll typically have more granular traffic identification and prioritization schemes that are easier to manage, such as GUI administration consoles, targeted just for shaping requirements (though some lack easy management of multiple devices). For example, Check Point's FloodGate-1 can already identify many applications because it inherits Check Point's FireWall-1 stateless inspection engine smarts. Other vendors that offer this service include Aponet and Xedia.

Two vendors are unique in shaping traffic using TCP rate control instead of queuing: Structured Internetworks (hardware-based), and Packeteer (software running on NT). Because many important applications use TCP to guarantee delivery, the products take advantage of TCP's windowing to burst data across the network more efficiently, and hog more bandwidth. To throttle down appl ication bandwidth consumption, these two traffic-shaping products rewrite the TCP windowing header information as traffic goes by.

Major arguments about which shaping technology approach offers the most capabilities still exist, but in the next year we'll see more evidence that proves that the customer implementation approach will work appropriately. Initial work with these products has centered on Internet traffic, specifically differentiating HTTP traffic by host versus more bursty FTP or audio and video traffic for an ISP, or Web-hosting implementations.

In the meantime, you may have to use different and perhaps parallel networks to accomplish multiple application loads appropriately. Interactive transaction traffic may indeed need to flow over frame relay networks, while multicast video and large file transfers go over VSAT.

Scheduling Rush Hour I've heard that, for two weeks, L.A. actually had reasonable rush-hour traffic when the Olympics were in town. How did it work? The city planners convinced the corporations and individuals that traffic congestion would be so bad downtown that they'd need to change work habits. They staggered normal work hours to spread out what had been more of a single peak time. They also encouraged lots of telecommuting from home to eliminate travel altogether. People could get to the Olympics and their work faster than ever. Of course, everything went back to "normal" after the Olympics were over.

It just goes to show that changing application behavior can have profound effects on network utilization and user response time. Figuring out which applications need to be convinced to change is part of the battle. Even if they can't change, assuring that they'll get preferential treatment is left to the on-ramp metering and HOV approaches of traffic shaping.

Bruce Robertson is a program director with the META Group's Global networking Strategies service. He can be reached at Bruce.Robertson@metagroup.com.



On The Edge
By Art Wittmann
FreeWire
By Bill Frezza
Corporate View
By Brian Walsh
On The Wire
By Bill Alderrson and J. Scott Haugdahl


Updated December 5, 1997

Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers