×

SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

CHANNEL BY TOPICS


QUICK LINKS




 

Product_Reviews.gif (5213 bytes)
August 1999


The Cloud 1.1

Shunra Software, Ltd.
139 Kenilworth Rd.
Ridgewood, NJ 07450
Ph: 201-652-7366
Fx: 201-652-7734
E-mail: info@shunra.com
Web: www.shunra.com

Price: 2 Mbps versions: $3,000
(one license);
$2,700 (two–four licenses); $2,500 (five–nine licenses); $2,100 (10–24 licenses); $1,600 (25 licenses and up); add $1,000 for 10 Mbps versions; annual maintenance contracts start at $395.�

RATINGS (0–5)
Installation: 5
Documentation: 4.5
Features: 4.5
GUI: 4.5
Overall: A-

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.
fig1.GIF (35140 bytes)

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.







Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: tmc@tmcnet.com.
Comments about this site: webmaster@tmcnet.com.

STAY CURRENT YOUR WAY

© 2020 Technology Marketing Corporation. All rights reserved | Privacy Policy