Robbing Peter to pay Paul

We've mentioned in a couple of newsletters that some intelligent DSU/CSU vendors have begun to bundle traffic shaping capabilities into their products. Such capabilities are designed to add value to these devices, which already have become valuable tools for network performance monitoring, trending, and analysis. Traffic shaping refers to certain quality-of-service (QoS) capabilities, most notably limiting the rate at which traffic generated from a given application can flow. In an integrated packet network, such as frame relay or IP, this prevents a single application from "hogging" all the bandwidth during periods of congestion.

We received a vehement reply to our observations recently. One of our readers strongly advocated running these QoS capabilities in the network router rather than in the DSU/CSU. The main argument was that the router and the network are already doing some aspect of traffic shaping, and that adding another device to the network that does the same thing would create an "administrative nightmare" for the customer. In addition, according to our reader, from a scalability and performance perspective, running this function in the smart DSU/CSU likely comes at the expense of CPU cycles and additional latency.

We'd like to hear your opinions, but it should come as no surprise that we have a few of our own. It would seem that first, the router already has plenty to do without adding CPU cycles for traffic shaping. In other words, such functions do consume processing cycles, but whether the performance hit comes in the router or in the DSU/CSU seems to add up to a "rob Peter to pay Paul" scenario. We advise that if you are looking for these capabilities, investigate the models of routers or DSU/CSUs that have been optimized to handle this functionality.

In terms of adding complexity to administration, this would be a drawback if you were considering investing in enhanced DSU/CSUs strictly because of the traffic-shaping capabilities. If you already are running an enhanced DSU/CSU for monitoring the performance of your frame relay virtual circuits, though, you've already added the device to your management mix, so getting more value out of it could prove economical and accelerate your return on investment.

One interesting point that our reader made, which we will explore in more depth in an upcoming newsletter after some investigation, is how traffic shaping in the DSU/CSU jibes with the budding standards for enterprisewide policy networking. Emerging policy servers enable network managers to use a simple interface to enter the business traffic priority information into an application that translates this information into a language the network devices - namely, routers - can understand. The policy management application and routers communicate this information to each other using the Common Open Policy Service (COPS) protocol. This way, a whole network of routers running COPS interprets the enterprise's networking priorities and policies in a common way and treats the traffic accordingly. So far, enhanced DSU/CSUs have not been part of the overall policy networking architecture.

Our guess for now: We predict there will be announcements stating that enhanced DSU/CSUs are becoming "COPS-compliant." Also, watch for signs that routing companies are buying or forming strategic partnerships with service-level management companies (Packeteer, NetReality and the like) that focus on traffic shaping and QoS capabilities.

To participate in an online chat on these and other WAN issues with Steven Taylor, Joanie Wexler and your fellow frame relay newsletter subscribers, please visit the Webtorials.Com Public Forum at www.webtorials.com/forum.htm.

RELATED LINKS