Proof is in the packets

There’s an old joke about an accountant’s job interview, and the punch line translates easily into network performance testing: The interviewee is asked to total last year’s figures and gets the job when she asks the questioner, “What would you like the total to be?”

This issue surfaced for Alyson Behr during her firewall/VPN test. Two of the vendors based their published numbers on TCP performance, and the other used figures generated with UDP (User Datagram Protocol) traffic because the results looked better that way. That’s not the vendors’ fault; the problem exists because there’s more than one way to transport data over IP.

The choice is usually between TCP and UDP. The basic difference between the two is simple enough: TCP is connection-oriented, using the endpoints to negotiate the data transfer; UDP is connectionless, with no flow control or error checking. Or to use a mail-room metaphor, TCP makes you sign for the package, whereas UDP just chucks the package through the door without looking to see whether it’s open.

UDP is used most frequently for services that don’t require much more than packet delivery and reassembly into datagrams — broadcast and multicast scenarios are excellent examples. NFS also uses UDP because the low overhead of the transport protocol easily accommodates large chunks of data. UDP is “lighter” on the wire than TCP; the negotiation and error-checking that takes place with TCP eats up bandwidth and is the price to pay for a reliable transport protocol.

Reflecting on the UDP-based protocols I’ve listed so far, I’m certain of one thing: Most of these have no business passing through firewalls. In many cases, the only UDP traffic that needs to cross between a corporate network and the Internet is DNS and NTP (Network Time Protocol). There are two big exceptions: VoIP and videoconferencing almost always rely on RTP (Real-Time Transport Protocol), an application-facing “top-up” transport protocol that relies on UDP in most implementations. But many VoIP and videoconferencing vendors are adapting their products to run via TCP because of customers’ reluctance to open firewalls to anything riding UDP.

Because so much of what people consider “the Internet” is TCP traffic, performance numbers that are based solely on UDP don’t tell the true story. Vendors, if your firewall handles UDP that much better, here’s an idea: Sell the box as a firewall designed for streaming media, videoconferencing, or VoIP. Then, those customers who need a firewall for bread-and-butter network traffic can look elsewhere.