Network Computingwww.networkcomputing.com

The PacketShaper discovers and controls more than 200 traffic types by using application signatures, not just TCP and UDP port numbers. Unlike many other traffic tuners, it can classify non-IP flows, including those using AppleTalk, IPX and SNA. It can identify about 30 new traffic classes, including RTP (Real-Time Protocol) and RSVP (Resource Reservation Protocol).

Active Intervention

The PacketShaper's traffic-management technique also sets it apart. While most other bandwidth-management devices rely on queuing mechanisms, the PacketShaper actively intervenes in TCP connections between end stations to control bandwidth and latency. The appliance alters TCP window size, maximum segment size, retransmission times to control congestion and other parameters. Packeteer says this approach offers more precise control over TCP flows than do queuing algorithms.

Products use one of two mechanisms to prioritize IP traffic: queuing or TCP rate control. Packeteer is the foremost advocate of the latter; its products alter TCP window size and other parameters to shape traffic. Other vendors use queuing, a technique in which devices place different classes of traffic in different queues and service those queues with greater or lesser frequency, depending on that traffic's priority.

After evaluating a beta of PacketShaper 2500 version 5.0, I agree with Packeteer's approach. The unit efficiently enforced just about every policy I set for TCP traffic. My only complaint was that the beta version I tested wasn't as effective in controlling UDP flows.

Setting up the PacketShaper is a snap. Both Web and command-line interfaces are available; I opted for the latter. The administrative shell asked me a few questions about my addressing and interface requirements, and in less than two minutes, I was ready to go.

The first step, traffic discovery, is probably the PacketShaper's slickest feature--other traffic shapers don't autodiscover traffic as easily or present the results in one tidy screen. I attached the unit to an Internet access router at our lab and let it run over several days. Then I fired up a browser, and the PacketShaper offered a detailed profile of our network traffic, including current and peak rates for all applications, the number of instances of each application and a summary of Packeteer's effectiveness in enforcing any rules I'd configured.

Bonus: Intrusion Detection

One thing that caught my eye right away was a couple of attempts to start inbound sessions from Symantec Corp.'s pcAnywhere. Since we don't run that application in the lab, I suppose it can be said the PacketShaper offers lightweight intrusion detection, too.

To get a sense of how well the PacketShaper actually controlled traffic, I unhooked the unit from the lab's production net and put it on a test bed. I began with baseline measurements of forwarding rate and latency to see what performance penalty the device itself imposed. I ran two sets of tests: one with traffic shaping disabled (to see how fast the unit would run) and then again with shaping turned on (to see how effectively it controlled bandwidth).

The unit I evaluated is engineered to control traffic headed to and from WAN pipes running at E1 (2.048 Mbps) or slower, so theoretically any higher rate would suffice. Even when handling flows consisting entirely of short (64-byte) packets, the PacketShaper didn't start dropping traffic until offered loads exceeded 55 Mbps. Latency was also low and constant, with measurements around 500 microseconds, even for long (1,518-byte) packets.

After I enabled traffic shaping and configured the PacketShaper to constrain bandwidth to T1 (1.544 Mbps), I was able to send UDP traffic through the PacketShaper at rates of up to 2.3 Mbps--or around 50 percent faster than the shaping contract was supposed to allow. Packeteer attributes the speed overrun to the beta software I tested.

The PacketShaper behaved much better with TCP traffic. In every test I ran, the PacketShaper enforced to the letter the contracts I set up for various classes of TCP.

I then ran another baseline test to determine how many concurrent TCP connections the device could handle. I used Tarantula from ArrowPoint Communications (now Cisco Systems); this device opens TCP connections and downloads 246-byte HTML objects to verify each connection. I got close to 8,200 concurrent connections before transfers started to fail--and that's enough for a unit designed to police a T1/E1 link.

Going With the Flows

PacketShaper also proved effective in a test scenario I ran emulating multiple flows from a branch office. Using the Chariot traffic generator from NetIQ, I set up seven concurrent sessions--four bandwidth-hogging file transfers, a RealMedia stream and two mission-critical sessions (in this case, SAP R/3 purchase orders). Although the file transfers alone were capable of saturating a 100-Mbps Ethernet segment, all these flows had to contend for the same 2-Mbps WAN pipe.

My "before" picture--that is, before I enabled traffic shaping--wasn't very promising. The file transfers used up more than 90 percent of all available bandwidth, pushing response time for the SAP sessions to nearly five seconds, far above the one-second limit considered optimal.

Then I enabled traffic shaping. In this case, I set up a rule that restricted all file-transfer connections to 300 Kbps, with the ability to burst to a maximum of 512 Kbps if other applications didn't need the capacity. Chariot itself limited RealMedia, which runs over UDP, to an offered rate of 300 Kbps; given that my earlier baseline results suggested the PacketShaper isn't very effective at shaping UDP traffic to specific rates, I didn't attempt a UDP overload.

The difference was remarkable. Average response time for the SAP sessions fell to 0.7 seconds, which was well below the one-second threshold for acceptable performance. And the aggregate file-transfer bandwidth averaged 473 Kbps, just as the rule dictated.

The PacketShaper differs from most competing products in that it controls throughput and latency by actively changing TCP characteristics, such as window size (the number of bytes outstanding before an acknowledgement is required) and maximum segment size (the number of TCP bytes per packet). My tests suggest the PacketShaper's TCP rate-control mechanisms are accurate.

David Newman is president of Network Test, a benchmarking and network design consultancy in Hoboken, N.J. Send your comments on this article to him at dnewman@networktest.com.