Burst Traffic scripts

In the burst traffic mode, the hosts under test transmit data every some specific intervals, specified by the burst period as shown in the scripts below. The burst size and the burst period is passed as a parameter by the user. This mode is very useful in real world experiments where rate mismatches might reduce the throughput dramatically. As an example of this is TCP over ATM architectures. It has been proven that rate mismatch 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 denote 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.

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

cluster {

test roadrunner {

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

}

test hopper {

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

}

}

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 calculated by:
 

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

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


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

parallel {

cluster {

test wiley {

type = burst (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 = burst (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 = burst (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 multi-casting, where three TCP sources transmit data to one receiver simultaneously, at a rate of (37500 * 8)bits/10 ms = 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 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|