Using Chariot to

Incrementally Test VoIP

Traffic Capacity
Application Note
by John Q. Walker, NetIQ Corporation

Contents

johnq@netiq.com

Introduction ............................... 2
Test Methodology ...................... 2
Scaling to Larger Tests.............. 3
Copyright Information .............. 4

Copyright ? NetIQ Corporation 2000.

Introduction
Our goal is to load traffic into the network, simulating the addition of Voice over IP (VoIP) conversations.
As more traffic is added, what happens to the devices in the middle of the network, to the VoIP traffic
itself, and to the other traffic in the network? Well add conversations one at a time, seeing what happens
at each incremental step.
H.323 VoIP traffic generally consists of three sequential parts: setup (a Q.931 and H.245 TCP exchange),
two RTP connections (for the two-way voice conversations), and the takedown. Well focus on the setup
and voice conversations, since they are the important elements in determining capacity and side effects.
A representation of the data flows is shown below in Figure 1.

Figure 1. An overview of the flows involved with a H.323 VoIP telephone conversation.

Test Methodology
Using a protocol analyzer or NetIQs AppScanner, the first step is to build Chariot application scripts to
emulate the TCP setup sessions. Also, take timings of the expected normal setup time. You may need to

fashion the data payloads to exactly replicate real setup. If so, create up to ten .CMP files for the
send_datatype variable to get the payloads right.
Next, build a streaming script for the RTP session. The key parameters are the RTP header value, the
datagram size, and the send data rate. The port number may also be important or port numbers may be
dynamically allocated. Use the value NOCOMPRESS for the send_datatype variable.
Save these TCP and RTP application scripts with unique filenames, so you can use them in multiple tests.
Dont just make the change in the Chariot testfile itself it makes it too hard to re-use them later.
Heres how to build a Chariot test for just one telephone conversation:
Pair 1: TCP setup script, from A to B (shown as Alice to Bob in Figure 1)
Pair 2: RTP script, from A to B
Pair 3: RTP script, from B to A
In the RTP scripts, set the initial_delay variable to the duration of the setup time, so that they start after
the setup has completed. For example, if Pair 1s duration is 2 seconds, set the initial_delay variable in
the script used in Pair 2 and Pair 3 (the same script) to 2000 milliseconds. Lets call this setup duration
value D1.
Run the test for a fixed duration, and return the timing records using Batch. Id suggest running the test
for about 5 minutes (more on this later). When the test is complete, look at the Lost Data and Jitter charts
and numbers for the 2 RTP scripts. For this simple test, they should be zero.
Now, lets test 10 conversations, adding one at a time rather than starting all ten at the same time. In
Chariot, highlight the three pairs we already created, and replicate them 9 times, resulting in 30 pairs.
Pairs 1, 4, 7, 10, etc will be the setup pairs, and the others will be the RTP sessions. How long to pause
before starting another conversation? Id guess 5 seconds (5000 milliseconds) would be good lets call
this delay value D2. In Pair 4, edit the script, and set the initial_delay to D2. In pairs 5 and 6, set the
initial_delay to D1+D2. In Pair 7, set the initial_delay to 2*D2; in pairs 8 and 9, set it to (D1+2*D2).
Youve got the idea its a little tedious the first time, because there isnt a way to group edit the
contents of a script, but the whole process shouldnt take more than a few minutes. Save the test, and
then run it for 5 minutes. If delay D2 was 5 seconds, it should take less than a minute to fully warm up,
and then run all ten conversations full out for the remaining 4 minutes. How much jitter? How much
lost data?
Incrementing the delays for each group of three pairs may be unnecessarily granular. You might want to
consider making five or ten conversations at a time have the same delay values, making the test creation a
bit less tedious.

Scaling to Larger Tests

You can clearly repeat these steps for 100 or 1000 conversations. If this is really where youre headed, let
our support team know we have an ASCII tool we use internally for creating and editing Chariot
application scripts. We could easily create a small Perl program to generate and uniquely name the
scripts, then combine them into prebuilt tests. I think the parameters to the Perl program would be D1,
D2, and N, the number of pairs to count up to. You may also need to run for a longer duration,
depending on D1, D2, and N (the maths pretty easy). In fact, you may want to consider running for
hours on end to see what happens and do all kinds of variations on this where you add other traffic,
and see what happens to that traffic. The additional/alternate traffic can be generated by other
endpoints, but be encompassed all in the same test, making it completely repeatable. Another good test
is applying different QoS techniques (e.g., RSVP, DiffServ, traffic shaping) to any of the traffic classes.
Copyright ? NetIQ Corporation 2000.

You can use just two IP addresses, that is two endpoints, to generate up to about 100 of these sessions. At
some point in that order of magnitude, you start to run up against the CPU, RAM, operating system, and
TCP/IP stack capacities of modern PCs and UNIX computers. If youd like to use several more endpoints
to do the traffic generation, you can use Chariots CLONETST command-line utility to do bulk address
changes with a Chariot test file. You might also want to use different IP addresses for every one of the
sessions. Weve seen Windows 2000 endpoints able to handle as many as 2500 different virtual IP
addresses simultaneously.

Copyright Information
NetIQ Corporation provides this document as is without warranty of any kind, either express or implied, including, but
not limited to, the implied warranties of merchantability or fitness for a particular purpose. Some states do not allow
disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to you. This
document and the software described in this document are furnished under a license agreement or a non-disclosure
agreement and may be used only in accordance with the terms of the agreement. This document may not be lent, sold, or
given away without the written permission of NetIQ Corporation. No part of this publication may be reproduced, stored in
a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, with the prior written
consent of NetIQ Corporation. Companies, names, and data used in this document are fictitious unless otherwise noted.
This document could include technical inaccuracies or typographical errors. Changes are periodically made to the
information herein. These changes may be incorporated in new editions of the document. NetIQ Corporation may make
improvements in and/or changes to the products described in this document at any time.
1995-2000 NetIQ Corporation, all rights reserved.
U.S. Government Restricted Rights: Use, duplication, or disclosure by the Government is subject to the restrictions as set
forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause of the DFARs 252.227-7013 and
FAR 52.227-29(c) and any successor rules or regulations. AppManager, the AppManager logo, AppAnalyzer, Knowledge
Scripts, Work Smarter, NetIQ Partner Network, the NetIQ Partner Network logo, Chariot, Pegasus, Qcheck, OnePoint, the
OnePoint logo, OnePoint Directory Administrator, OnePoint Resource Administrator, OnePoint Exchange Administrator,
OnePoint Domain Migration Administrator, OnePoint Operations Manager, OnePoint File Administrator, OnePoint Event
Manager, Enterprise Administrator, Knowledge Pack, ActiveKnowledge, ActiveAgent, ActiveEngine, Mission Critical
Software, the Mission Critical Software logo, Ganymede, Ganymede Software, the Ganymede logo, NetIQ, and the NetIQ
logo are trademarks or registered trademarks of NetIQ Corporation or its subsidiaries in the United States and other
jurisdictions. All other company and product names mentioned are used only for identification purposes and may be
trademarks or registered trademarks of their respective companies.