Queued Burst Traffic scripts

In the queued burst traffic mode, the hosts under test transmit data every some specific intervals, specified by the burst period as shown in the scripts below. This mode is a variation of the basic burst algorithm and the burst size and burst period are passed as a parameter by the user. The advantage of this algorithm is that variations in available line rate will not cause it to miss blocks generated by interrupts arriving before previous write completes. The drawback is that characteristics of the traffic are influenced by the queueing dela The usefulness of this mode is similar to that of the burst mode, since basically they achieve application level traffic shaping, which is necessary where rate mismatches are present, that will reduce the throughput dramatically. As an example of this is TCP over ATM architectures. It has been proved that rate mismatching reduces throughput, and that's why traffic shaping must be enforce on the source end systems to boost performance. Therefore, running the appropriate scripts on this mode, one can shape the source traffic to a desirable rate which matches the destination or the link rate. This mode is tested over LANs, WANs, and satellite environments with incredible results.

The bold words in red in the following example scripts denode key words. Bold blue letters denote key words again, but those can be changed by another NetSpec option. Table 1 explains all the key words used in the following scripts.

Queued Burst Traffic: Script #1; Point-to-Point Traffic shaped at 100 Mbps;

cluster {

test roadrunner {

type = burstq (blocksize=125000,period=10000, duration=10);
protocol = tcp (window=1048576);
own = roadrunner.atm:45000;
peer = hopper.atm:45001;

}

test hopper {

type = sink (blocksize=125000, duration=10);
protocol = tcp (window=1048576);
own = hopper.atm:45000;
peer = roadrunner.atm:45001;

}

}

All the key words are explained in Table 1. The first block specifies the characteristics of the traffic source, while the second block specifies the characteristics of the receiver host. The sender and receiver TCP systems used are machines in the local ATM network in the University of Kansas (KU). This script can be used in testing the performance in a LAN and a WAN, as well as testing the performance over a satellite link, where traffic shaping is necessary due to link mismatches. The traffic in this script is shaped to 100 Mbps. This is calculted by:
 

Throughput = (blocksize * 8)/(period * 10^(-6)) [b/s]

Where blocksize and period(in micro secs) are the values used in the script.


Queued Burst Traffic: Script #2; Parallel Connections; traffic Shaping at 30 Mbps per host

parallel {

cluster {

test wiley {

type = burstq (blocksize=37500,period=10000, duration=600);
protocol = tcp (window=10485760);
own = wiley.atm:45000;
peer = faraday.atm:45001;

}

test faraday {

type = sink (blocksize=37500, duration=600);
protocol = tcp (window=10485760);
own = faraday.atm:45000;
peer = wiley.atm:45001;

}

}

cluster {

test galaga {

type = burstq (blocksize=37500, period=10000, duration=600);
protocol = tcp (window=10485760);
own = galaga.atm:45002;
peer = faraday.atm:45003;

}

test faraday {

type = sink (blocksize=37500, duration=600);
protocol = tcp (window=10485760);
own = faraday.atm:45003;
peer = galaga.atm:45002;

}

}

cluster {

test elmer {

type = burstq (blocksize=37500, period=10000, duration=600);
protocol = tcp (window=10485760);
own = elmer.atm:45004;
peer = faraday.atm:45005;

}

test faraday {

type = sink (blocksize=37500, duration=600);
protocol = tcp (window=10485760);
own = faraday.atm:45005;
peer = elmer.atm:45004;

}

}

}

All the key words are explained in Table 1. This script carries out a performance evaluation test of 3 TCP parallel connections where traffic shaping is performed. It's a good example of multicasting, where three TCP sources transmit data to one receiver simultaneously, at a rate of (37500 * 8)bits/10ms = 30 Mbps each TCP source host [This comes out to an aggregate paced throughput of 90 Mbps].

The above script was used to evaluate the performance of TCP/IP hosts on ATM networks over an OC-3c satellite link. Since the OC-3 satellite link wouldn't be able to forward cells coming from the three OC-3c TCP over ATM connections as fast as the incoming rate, congestion will take place, cells will be dropped at the ATM switches, TCP retransmissions will take place and thus throughput will degrade. Therefore using NetSpec in queued burst mode and pacing the traffic to an appropriate aggregate rate, one can avoid overflowing the link and thus keeping performance to a descent level. The same script can be modified to be used with UDP [just change TCP to UDP and delete the window = parameter], or with serial connections [just change parallel to serial]. It can support an arbitrary number of parallel or serial connections (point-to-multipoint, multipoint-to-point) and can be used on any network architecture or size.


|Table 1| |TOP|Introduction to NetSpec| User NetSpec scripts|