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
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.
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
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.
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,
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.
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 3Coms decision to buy was based on
U.S. Robotics without Palm.
There were rumors that Palm didnt 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 arent selling well against Palms Pilot,
Id guess battery life is 95 percent of the explanation.
Just my 2 cents.
Mountain View, CA