ICMNetGen
ICMNetGen, which extends the functionality of the existing Client and Server test programs, tests
network connectivity, throughput and prioritizations. The tool runs on a Client/Server model. The client
connects to a server and sends a sequence of messages to the server. The server echoes back to the client
any messages it receives. ICMNetGen measures and reports the round trip times of EMT messages and
TCP packet transmissions/retransmissions.
For example, ICMNetGen can work on the following scenarios:
1. Test Link Quality
The pre-QoS EMT protocol uses UDP heartbeats to tell the other end of a connection that the sending end
is still operational. If heartbeats are not acknowledged, the other side declares a problem after five
heartbeats are missed. ICM administrators can get an idea of the underlying communication link quality
by counting the number of lost heartbeats.
In a convergence network, however, router algorithms to handle network congestion conditions have
different effects on TCP and UDP. As a result, delays and congestion experienced by UDP heartbeat
traffic can have in some cases little correspondence to network. For this reason, UDP heartbeats are
replaced by TCP keep-alive messages in a QoS-enabled EMT library.
While TCP keep-alive messages are able to detect the inactivity of the other side as UDP heartbeats do,
they do not indicate communication link quality because they are sent in the absence of data. Thus, they
are opaque to ICM administrators.
ICMNetGen contains an IP traffic sniffer that uses the real-time capture interface (IRTC) of Microsoft
Network Packet Provider (NPP). It is able to capture IP datagrams and keep track of TCP activity. For
example, if the network fails occasionally, setting the message generation rate high enough and then
checking the packet retransmission ratio or packet loss rate can help detect network failure.
2. Validate DSCP Marking
To ensure that intervening routers do not mark or remark DSCP code points, you can launch ICMNetGen
with a specific DSCP value and then turn on the tracing on the IP sniffer. Since each captured IP
datagram is dumped on the screen, the DSCP code points of incoming IP datagrams can be validated.
However, ICMNetGen cannot detect if packets get remarked and then un-remarked by intermediate
routers.
3. Load Test
ICMNetGen does not have to be run in parallel to true ICM traffic. During the network
planning/deployment stage, network administrators can run the tool to test the amount of traffic the
network can support without starting ICM services. This test is done by generating multiple traffic flows,
each of which has a specific DSCP code, message length, and traffic load. The throughput and response
time for each traffic flow are measured. The traffic load is increased in stage until the round-trip time no
longer meets requirements.
Command Line Format
The ICMNetGen.exe file is copied to the “icm\bin” directory when ICM setup runs. It can be started as
either a Client (by default) or a Server (by the switch parameter /server). For the command line format,
type in “ICMNetGen /?”:
Of those parameters on the preceding screen, the following parameters apply to both ICMNetGen Server
and Client:



ServerIPAddress – the hostname or dotted IP address to connect to.

trace – the tracing mask: “/trace 0”, no IP frame tracing (by default); “/trace 1”, display a summary of
the captured frame; “/trace 2”, in addition to the summary, dump the first 74 bytes of the captured
frame including the Ethernet header.

ReportInterval – the interval, in messages, at which message RTT and TCP activity are reported.
Default is 50 messages.
ServerPortNumber – the port number to connect to.
[/server] – the switch parameter to launch ICMNetGen as the Server. Otherwise, it starts as the
Client.
The following parameters apply to ICMNetGen Client only:

ClientIPAddress – the local hostname or dotted IP address to use as the source of the connection. It
may be necessary to specify this if the client machine has more than one network interface or IP
address.


MessageInterval – the interval, in milliseconds, between messages. Default is 1000 milliseconds.

MessageSize – the size of each message, in bytes. Default is 1024 bytes. The size specified is in
addition to TCP, IP, and link level headers.

BucketCount – the number of histogram buckets to display at each report interval. The client program
displays a histogram of round-trip times with BucketCount buckets each report interval. The default is
20 buckets.


BucketSize – the size, in milliseconds, of each histogram bucket. The default is 100 milliseconds.
BurstCount – the number of messages to send at each message interval. Default is 1. If greater than 1,
BurstCount messages are transmitted as rapidly as possible before waiting for the next message
interval.
MessageDSCP – the DiffServ codepoint of messages. Default value is “000000”, the intended use for
Best Effort. The server side will use the same value for message echoes.
Settings and Risks
The Network Monitor driver must be installed in order to run ICMNetGen. If it is not installed,
ICMNetGen prints out an error message:
“No Network Monitor Driver! GetNPPBlobTable(...) failed [3017]!”
To install the Network Monitor Driver, perform the following steps:
Open Network and Dial-up Connections in Control Panel.
1. Right click the network connection where you would like to install Network Monitor Driver, and then
select Properties.
2. In the Connection Properties dialog box, click Install.
3. In the Select Network Component Type dialog box, click Protocol, and then click Add.
4. In the Select Network Protocol dialog box, click Network Monitor Driver, and then click OK.
5. If prompted for additional files, insert your Windows 2000 CD-ROM, or type a path to the network
location of the files.
1.1.1 Notes
ICMNetGen reports the true bidirectional traffic volume generated at every report interval (controlled by
the optional parameter ReportInterval). It also indicates network congestion if the report volume is less
than the twice that of the one-way traffic volume you specified in the command line.
If Microsoft QoS Packet Scheduler is installed, ICMNetGen sees a duplicate from the Packet Scheduler
Traffic Control interface in addition to the frame captured from the device driver. For this reason,
uncheck the QoS Packet Scheduler component in the Connection Properties setup dialog box if
ICMNetGen is intended to be used for calculating RTT and TCP statistics.
Be careful of running ICMNetGen in parallel to true ICM traffic, because the simulated traffic competes
with the true ICM traffic for network resources.
Examples
1. Test Link Quality
The first example tests whether any failures (such as high packet loss rate or high latency) are happening
in a network connection. On the server machine, the following command line is issued:
icmnetgen <server-ipaddr> 8000 /server
The connection is set up on the client machine with the following command line (continued lines start
with →):
icmnetgen <server-ipaddr> 8000 /localaddr <client-ipaddr> /msgintvl 100
→ /msgsize 100 /rptintvl 100
The client sends 100 bytes of data every 100 milliseconds. The measured performance is reported every
100 messages as the following screenshot shows:
In this example the mean message round trip time is 596ms. This does not meet the requirement for RTT
(less than 200ms) if the public high connection between the PG and the CC is tested.
2. Validate DSCP Marking
On the server machine, the following command is issued:
icmnetgen <server-ipaddr> 8000 /server /trace 1
On the client machine, input:
icmnetgen <server-ipaddr> 8000 /localaddr <client-ipaddr> /dscp 26 /trace 1
The parameter “/dscp 26” specifies the DSCP value of outgoing packets as 26. The “/trace 1” parameter
sets the briefed tracing mode (i.e., printing out the summary line for each captured frame). Since the
server uses the same DSCP value to bounce messages back to the client, the incoming packets are
expected to have the same marking as well.
The tracings on the server and the client, respectively, are shown in the following screenshots:
On both the client and the server machine, while the DSCP value of outgoing packets is marked correctly
as 26, the incoming packets have no markings at all (i.e., DSCP is 0). This shows that the intermediate
devices (router or switch) strip off the markings.
Notes
ICMNetGen will not be aware if packets get remarked and then un-remarked by intermediate routers.
TCP SYN packets and EMT handshake packets are not marked.
Client/Server
The Client/Server utility is the pre-QoS version of ICMNetGen. Refer to the previous section for usage
instructions, keeping the following differences in mind:
 The Client/Server tool uses UDP heartbeats to tell the other end that the connection is still alive.

The Client/Server tool does not mark and trace packets.