As more netwok-based software evolves into the WAN and telephony realms, developers and implementers face the task of predicting and troubleshooting application performance within the confines of evaluation laboratories or MIS rooms. This can be a daunting project, based too much on guesswork, experience, hunches, and trend spotting « not very scientific. Unfortunately, this environment is too common in the CTI field, and especially in the voice-over-IP (VoIP) realm.
A reasonably priced solution to this problem is The Cloud 1.1, from Shunra
Software, Ltd. Developers dreamed up The Cloud as a WAN emulator and testing tool for
their own internal research, but quickly realized its potential as a standalone product
line. Our own testing of The Cloud proved its ability: Its Lilliputian learning curve,
extensive feature set, and concise, well-written documentation impressed us. We tested the
10-Mbps version, although a 2.4-Mbps version is also available. (We also urge you to
consider the EMIP-1 testing tool, from CC&T Technologies, elsewhere in this issue.)
INSTALLATION
Installing The Cloud is very easy. System requirements include a Pentium or
better CPU running at a minimum of 133 MHz, and at least 32 MB RAM, 5 MB disk space, the
Windows NT 4.0 Server operating system with Service Pack 3 or higher, and a CD-ROM drive
or access to one over a network. The PC must also have a network card, although two
network cards are required to make The Cloud simulate a router between WAN legs. Once our
host PC was set up, installing Shunra’s software involved only a simple setup wizard,
which took just a few minutes to configure. The entire software portion took less than ten
minutes, which is phenomenal considering the unique power and features of The Cloud.
DOCUMENTATION
The Cloud comes with four main documents. The first is a user’s manual of
just 67 pages, organized into five chapters. The manual assumes a decent knowledge base of
IP networking, but there are sufficient explanations of most media-over-IP technical
terms, plus the standard number of charts, artwork, and context-sensitive button help
necessary to teach the software. The other documents include a white paper on IP testing,
a readme file that outlines what’s new in version 1.1, and a brochure titled
“Why emulate a WAN?” that is far more technical in nature than most other
marketing literature.
We especially like the to-the-point explanations of the user’s manual; for
example, it’s refreshing to see a sentence in the manual’s introduction that
reads “…The Cloud reduces much of the pain associated with testing different
network configurations.” This section of the manual goes on to discuss a real problem
(simulated testing versus real world testing), and what The Cloud does about it. We wish
all manuals were so honest! (Certain minor issues did arise with the user’s manual
— see the Room for Improvement section below.)
FEATURES
Simulation Mode
The Cloud begins every session in its simulation mode. The main interface
includes a pull-down menu and toolbar, and a simulation toolbar. The simulation toolbar is
simple but useful. From left to right, its six buttons are simulation start, simulation
stop, show packet lists window, show total throughput window, show throughput per packet
window, and show simulation mode. Meanwhile, the main pull-down menus are useful for
selecting features like template saving, views, options (for example, network adapter
preferences and memory/buffer settings), and help.
Simulation mode (Figure 1) shows a cartoon-like image of a
“cloud” (which represents your WAN, the Internet, a VPN, etc.) labeled simply as
WAN. The image also shows a “west gateway” and an “east gateway,” the
east side being the PC with The Cloud installed on it, the west side being the rest of
your network. The Cloud’s IP address is shown on the east gateway.
Figure 1. The Cloud:
Simulation Mode, where The Cloud defaults to upon opening. This view shows your WAN as a
cloud-like image, with an “east” and “west” gateway image representing
various nodes. This looks nice, but clicking on these images accesses the settings and
real power of the software. GUIs throughout The Cloud are laid out well and are easy to
learn.
Network Segment Configuration
The simulation mode may look nice, but The Cloud’s real beauty is below its
skin. By clicking on either side’s gateway, you can configure the bandwidth and
packet buffer parameters (although Shunra calls the buffer a packet “bucket”).
Bandwidth is configurable in 16 increments from 14.4 Kbps to unrestricted — some of
the intervals along the way include 56 Kbps, T1, and E1. Bandwidth can also be set for
asymmetrical values for the uplink and downlink (the same intervals apply).
Bucket limitation is the other main option on this screen. The bucket is the memory
buffer where packets or bytes are stored temporarily while they transition between hops,
routers, etc. For example, the buffer is used when packets or bytes arrive at the
receiving end of a path (like your PC’s network card) but before they go to the final
destination (like your handset or speakers). The first bucket option is called “drop
tail” mode — once the bucket is full, the whole bucket empties at once. There is
also a “random early detection” mode, in which a customizable minimum threshold
(designated in kilobytes) serves as a level where any new packets inserted into the bucket
create a message sent to the originating source to slow down the outbound packet speed.
There is also a maximum threshold, where new packets arriving at the bucket above the
threshold are automatically dropped, instead of dropping the incumbent bucket contents.
Like the values for bandwidth, the bucket levels can be chosen from a dropdown list, or
entered manually. We’d like to see the addition of a FIFO mechanism for emptying the
buffer packets.
Internet Recording: The Cloud Catcher
Clicking inside the WAN/cloud image brings up two options: One for manual Cloud
settings, and one for the “Cloud Catcher” settings. Essentially, the Cloud
Catcher (accessed by choosing the “Internet Recording” radio button) records the
latency, packet loss, and other conditions from the current atmosphere of your
organization’s actual network. This information is invaluable to network
administrators, because it enables testing of how the network will react to new
circumstances (for example, new client/server software or voice sent over IP) based on the
network’s own, quantifiable history. Without such a feature, this kind of
testing/network evaluation could be conducted with data based on guesswork or inaccurate
information that may or may not reflect realistic situations.
To configure the Cloud Catcher, users enter a destination IP address or DNS address,
plus the length of the recording session. Users can also choose the interval sample, in
milliseconds, and the packet length, in bytes. When the recording session is complete, a
summary graph (found by clicking on the latency button of the WAN parameters box) shows
the latency over time. Further options at this point include choosing “walk through
recorded WAN sequentially,” which plays back the recording exactly as recorded, and
which loops when finished, and “select random WAN parameters for each packet,”
which uses random latency figures from the recording throughout your tests. After a
decision is made, the final image shows a summary for the minimum, average, and maximum
latency and packet loss.
The Cloud Catcher also has an e-mail feature, which sends the Catcher’s executable
file and a parameters file (along with sender-configured parameters for the sampling
interval, recording time, and test packet length) to any Internet address, where the
recipient can run the file and bounce the results back to the sender. The files total just
306 KB. This is a good example of real-world usefulness for a testing tool.
Manual Settings
Armed with the Cloud Catcher data, or with hypothetical data that you’ve
decided will make a good testbed, configuring a Cloud WAN evaluation is a simple process
of pointing and clicking. There are many configuration options, including settings for
latency, packet loss, line faults, packet actions, and congestion. These options are
accessed by choosing the manual settings radio button in the Simulation Mode window. The
options here include:
- Latency. Can be fixed for a certain value, or can be set to reflect a
minimum-to-maximum range. There is also a “normal distributed latency” setting,
which reflects latency distributions based on standard deviations. All values are in
milliseconds.
- Packet Loss. Can be set for none, periodic (lose every Xth packet), random loss
(lose X percent of all packets), and burst loss (where you set the loss probability
percent and the minimum and maximum loss bursts).
- Packet Effects. “Special effects” for packet manipulation include a
misordered setting, in which you set the chance (in percent) of misordering, as well as
the minimum and maximum number of packets away they can be from the original location. The
second packet effect is duplicating, where you can set the chance of and minimum and
maximum number of packets that are sent twice. A final packet effect option is
fragmentation, which occurs when a packet is bigger than its allotted bandwidth. Here the
options include settings for the chance of fragmentation; the maximum transmission unit
(MTU) in bytes; whether or not packets should adhere to do not fragment (DNF) bits; and
whether or not fragmented packets should send diagnostic and tracking messages (ICMP bits)
to their source.
- Link Faults. To simulate actual connection errors, users can select the
statistical chances of a bit error happening (as low as once every millionth bit). Another
option is setting for the minimum and maximum number of bits to be toggled when an error
does happen. Meanwhile, Shunra engineers told us that they’re working on a way to
make the chances of an error be configurable to multiple decimal places beyond millions.
The next option under link errors is network disconnection, which can be set to happen
once every X seconds, for a minimum and maximum length of time in milliseconds.
- Network Congestion. Conges-tion can be set to occur once every X seconds, for a
minimum and maximum length of time in milliseconds, and for fixed amounts of latency and
packet loss percent to occur while the congestion event happens.
Network Monitoring
All the packet manipulation and data recording in the universe would be useless
if there was no way to analyze it. Toward that end, Shunra gave The Cloud three methods of
visualizing network performance under the conditions that you’ve set, in addition to
the latency, packet loss, and other figures shown in the Simulation Mode window. These
choices include the Packet List window, the Total Throughput window and the Throughput per
IP windows. All three windows can be dynamically updated in real time by enabling the Auto
Scroll feature.
The Packet List window is a table that logs every individual packet that passes through
The Cloud. Information on each packet includes its direction (west-to-east, east-to-west,
or dropped, all of which are color-coded), plus the time it was received, packet flags
(lost, misordered, duplicated, fragmented, etc.), its source IP port, its destination IP
port, its length (size), and the protocol extracted from its header. Also, the packet list
can display information about the packets coming from and going to any node on the WAN.
The Total Throughput window shows a line graph of all WAN traffic. The graph is updated
once per second and shows two lines — a blue line for east-to-west traffic, and a
green line for west-to-east traffic. Users can change the graph’s X and Y factors to
make the data easier to follow, and they can choose to see either line or both
simultaneously. Another option is the Throughput per IP window, which shows a bar graph
indicating the amount of data sent and received by each IP host node. Here, users can view
sent data, received data, or both.
Other Options….
The usefulness of The Cloud doesn’t end with its Internet Recording and
Manual Setting options. Users can also configure the actual size of the packet buffer,
plus the preferences of what should happen when the buffer is full — options include
continuing operation without updating the packet list, clearing the buffer and beginning
the capture of new packets, and stopping the simulation. All three options can also warn
the user before erasing any packets. Another interesting option is the command line
interface, through which certain options can be controlled. For example, the command
CloudPlay <filename> launches The Cloud and a file, and CloudStop <filename>
stops the simulation and saves the results. Finally, other options include the ability to
select which network adapters The Cloud should recognize as its gateways to the WAN, an
option that controls how The Cloud service uses NT’s IP forwarding, and a template
feature through which users can choose Cloud settings for saving .WST files — much in
the same fashion as a Word document can have a .DOT template file. Standard Cloud files
use the .WSF extension.
OPERATIONAL TESTING
When a Shunra engineer came to demonstrate The Cloud’s abilities to us, we
started with some basic tests once the installation was complete. First, as noted in the
user’s manual, working with smaller packet sizes makes the results more accurate and
easier to read in graph form, although smaller packets also mean that you’ll need
more drastic packet manipulations to see the effects on network performance. For the
simplest test, which was designed more to ensure that the software was working, we issued
a ping command from a PC on the network to the PC housing The Cloud. The result came back
with about 5 ms of latency, round-trip. Then, we set The Cloud to issue 50 seconds of
latency, and with the next ping command, the round-trip time was 100 ms.
Thus, we confirmed that the system was working. From here, we continued to issue more
complex settings with more parameters enabled, such as a test that configured The Cloud to
issue 100 ms of latency in 100-percent bursts every four seconds, followed by four more
seconds of disconnect time, then four seconds of normalcy. Sure enough, when we pinged
again, the results came back as 200 ms round-trip for four tries (trying once per second),
followed by four ping failures, followed by four normal 5-ms trips. Clearly, the
usefulness of The Cloud is limited only by the creativity of the user. (Another
interesting test is to watch the various monitoring windows as the tests run, especially
when they are scaled down to the single-unit X and Y ratios.)
As explained in Shunra’s “Why emulate a WAN?” brochure, there are many
places where this product can be put to the test: You can stress-test your network before
implementing new software; you can test your software from the end-user perspective; you
can analyze bandwidth requirements; you can define and verify service-level and
quality-of-service agreements.
For a more advanced test, we installed a second network adapter on Shunra PC, using
that computer as a router between LAN segments. Once the two LANs were configured to talk
to and trust each other’s users, we sent standard Ping commands across the WAN, with
The Cloud software disabled. Then, we tested several applications within versions 2.11 and
3.0 (still in beta form) of Microsoft’s NetMeeting client, including video
conferencing, text chat, whiteboarding, file sharing, applications sharing, etc. As we
expected, the most network-intensive applications were video conferencing and application
sharing. Our test network was entirely 10Base-T, and by experimenting with different Cloud
settings (like packet loss, congestion, fragmentation, bursts, etc.), we were able to
eventually overload the test network until NetMeeting itself and even network browsing
within Windows Explorer became extremely slow (bogged down by network degradation). By
doing this test, we could see how a real developer or network administrator would use The
Cloud for stress-testing a real network, especially a network with critical applications
like Exchange Server, a VPN, a secure transactions server, etc.
ROOM FOR IMPROVEMENT
We’re extremely pleased with The Cloud’s effectiveness, but there are
some areas where we’d like to see improvement. As we explained above, Shunra
engineers are already working on a way to “drill down” past one per every
million chances of a bit error, and we’d like to see a way to automatically cut and
paste the results of a WAN-wide Cloud Catcher test to the actual Cloud settings. We’d
also like to see a Web-based client for uploading test parameters, although in certain
circumstances, the Cloud Catcher approaches this functionality. We’d like to see an
appendix to the user’s manual that discusses real-world testing of different types of
applications in detail, to give end users more of a reference point from which to begin
testing (sample template files are already included, however). Finally, although the
software is easy to learn, the manual does jump from place to place, and there are some
cases where the grammar is hard to follow and terms may be misapplied.
As more network-based software evolves into the WAN and telephony realms, developers
and implementers face the task of predicting and troubleshooting application performance
within the confines of evaluation laboratories or MIS rooms. This can be a daunting
project, based too much on guesswork, experience, hunches, and trend spotting — not
very scientific. Unfortunately, this environment is too common in the CTI field, and
especially in the voice-over-IP (VoIP) realm
CONCLUSION
The Cloud is the kind of product that’s so valuable that we plan to use it
in-house, especially for testing voice-over-IP technologies, and possibly even for our MIS
department to stress-test our own corporate network before implementing new applications.
For its price point, even at the most advanced level, this product offers an excellent
combination of features, learning curve, and brute power. We highly recommend The Cloud,
and honor it with our Editors’ Choice Award. However, some users might be better
served by CC&T’s EMIP-1 tool (also reviewed in this issue), which has a slightly
different but useful feature set, and which costs less and includes an industrial PC
running the Red Hat Linux operating system. |
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
