February 2000

To the Editors,
I read Christofer Stahl's letter in the November 1999 issue of Internet Telephony with some interest. Netcom Systems is the industry-standard network performance measurement. I suspect that he has experienced so much difficulty in obtaining the packet forwarding performance information because these statistics can vary significantly depending on the configuration of the device and on the style of traffic being forwarded.

For example, short packets will stress forwarding much more than longer packets. This impact is due to the lookup that must be performed by the forwarding device every time a packet is received to determine the output port based upon the packet contents. Shorter packets generate more lookups per unit time and therefore can lead to more loss, jitter, and latency when the forwarding device is heavily loaded.

In addition to packet size, the traffic patterns that are generated can also dramatically effect performance. Consider the case of a forwarding device that has a backplane capacity of 10 gigabits per second and port capacity of 20 gigabit Ethernet ports. This device cannot theoretically forward all packets at line rate if they all must traverse the backplane when passing through the forwarding device. However, many vendors design their products under the assumption that some portion of the traffic will pass between ports on the same blade and that the remaining portion will pass over the backplane. Thus, if users that frequently communicate with one another are both connected to the same blade, the forwarding device should still perform quite well, but if more than 10 gigabits per second are forwarded over the backplane then the performance will be dramatically reduced.

Also, consider the much-discussed quality of service (QoS) implementations. QoS is now available from a number of vendors in various forms. Forwarding performance will vary substantially depending upon the QoS level assigned to the packet. Furthermore, because many vendors implement their QoS solution as Class of Service (CoS). In a COS solution some packets are given preferential treatment to other packets in the forwarding device. In contrast, QoS in its strictest terms is a guarantee on performance parameters such as loss, latency, and jitter. This technical distinction distills into a performance with CoS that is essentially relative to the other packets in the forwarding device at the same time. For example, a higher class of service might deliver packets with one half of the latency of a lower class of service, but no guarantee in absolute time regarding the latency of a particular packet through the forwarding device will exist.

In the end, our advice to end-users is to test any potential devices under typical and extreme network conditions. Vendors may provide numbers or metrics, but these numbers must also be provided with a test configuration. Furthermore, if this test configuration does not represent the end user's system, then the results of the testing should not be relied upon to predict performance in an alternate configuration.

Netcom Systems produces a number of products that can be utilized to performance test networking devices. In this particular case, I would recommend that Christofer investigate the possibility of utilizing our IP QoS performance test application, SmartFlow, to test the devices for which he is seeking statistics. He is quite correct to point out that one-way latency, jitter, and loss do dramatically effect VoIP performance, but he must be careful to test the forwarding devices in a realistic and well-controlled configuration in order to get meaningful results.

Thanks,
Glenn Chagnot

Thank-you very much for the excellent article (Mind Share, Internet Telephony� December 1999 about the 8x8 Audacity-T2 IP Telephone Processor. The article made a very big splash at 8x8 this morning with the managment team reading it with interest.

One enhancement not covered was to bring the first chip out in a 180-pin FBGA package instead of the 176-pin TQFP package. This change enables us to shrink the amount of PCB space needed for the IC to an overall 15mm x 15mm instead of the 26mm x 26mm for the TQFP.

Andy Huckridge,
Product Manager,
IP Terminal and Gateway Products, 8x8, Inc.

Thank you for your frank review of Rave 2. We have addressed many of the limitations mentioned in the article with our latest version, 2.04 (November 2, 1999)

We now have a range of codecs (including CELP, GSM, G711, G721, G723), which can be selected on-the-fly during a conversation, and auto VOX is now a default setting (which can be overridden).

The GUI is improved with a resizable window that supports ICQ group folders, and an ICQ message can be sent by right-clicking on a user name when offline (not talking). When online, jitter compensation (latency) can be easily adjusted from 0 to 3000 ms from the right-clicked pop-up menu. We have also added firewall, proxy server, and ICS (Internet connection sharing service) support. Lastly, we have a standalone VoIP phone in the pipeline that is not ICQ dependent.

This version can be installed over the top of the old.

Kind regards,
Mike Mee

The History Of Palm

In your “From Palm to WinCE” (Reality Check, November, 1999) you write that many questioned “the wisdom of 3Com buying up PalmPilot.” As I remember, Palm Computing was bought by U.S. Robotics. This was sensible. Palm had products like “PalmConnect for the HP 200” that fit right in with U.S. Robotics modems. Then 3Com bought U.S. Robotics, also a sensible deal. The two purchases were fairly close together; most likely 3Com’s decision to buy was based on U.S. Robotics without Palm.

There were rumors that Palm didn’t really fit with 3Com. This September 3Com announced it would spin off Palm.

Side notes: A Palm with a Ricochet modem velcroed to it has better speed and cost specs than the Palm VII, a Mobitex solution.

As far as why the WinCE products aren’t selling well against Palm’s Pilot, I’d guess battery life is 95 percent of the explanation.

Just my 2 cents.

Tom Day
Mountain View, CA