Full Stream Traffic scripts

In the full stream traffic mode, the hosts under test transmit data as fast as they can. This is the mode that ttcp supports. NetSpec on this mode can be used to estimate the maximum throughput that can be utilized in a specific communication channel, being either terrestrial or satellite. 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.

Full Stream Traffic: Script #1; Point-to-Point TCP Traffic

cluster {

test roadrunner {

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

}

test hopper {

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

}

}

All the key words are explained in Table 1. Generally, the script above is of the most widely type used for a TCP point-to-point connection. 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 WAN, as well as testing the performance over a satellite link, after the appropriate window size is specified for TCP using the bandwidth-delay product for achieving optimized performance.

In this particular example, the host with alias name roadrunner is the sender system and the host with alias name hopper is the receiver system. The sender sends data in full stream mode; it transmits 131072 bytes as fast as possible for 10 seconds (duration of experiment). For this data transfer TCP is used in the transport layer with a window size of 1 MB.


Full Stream Traffic: Script #2; Point-to-Point UDP Traffic

cluster {

test roadrunner {

type = full (blocksize=131072, duration=10);
protocol = udp;
own = roadrunner.atm:45000;
peer = hopper.atm:45000;

}

test hopper {

type = sink (blocksize=131072, duration=10);
protocol = udp;
own = hopper.atm:45000;
peer = roadrunner.atm:45000;

}

}

All the key words are explained in Table 1. This script can be used for performance evaluation of a point-to-point LAN and WAN communication link (terrestrial or satellite) where the UDP protocol is used instead. The block structure is the same as in script #1. The only difference is that the UDP protocol is specified instead of TCP, and no window size is needed; UDP just sends IP packets without scaling windows or retransmission schemes.

In this particular example, the host with alias name roadrunner is the sender system and the host with alias name hopper is the receiver system. The sender sends data in full stream mode; it transmits 131072 bytes as fast as possible for 10 seconds (duration of experiment). For this data transfer UDP is used in the transport layer.


Full Stream Traffic: Script #3; Parallel Connections

parallel {

cluster {

test wiley {

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

}

test faraday {

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

}

}

cluster {

test galaga {

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

}

test faraday {

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

}

}

cluster {

test elmer {

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

}

test faraday {

type = sink (blocksize=131072, 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. It's a good example of multi-casting, where three TCP sources transmit data to one receiver simultaneously. The above script was used to evaluate the performance of TCP/IP hosts on ATM networks over an OC-3c satellite link, under congestion conditions. 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.

In this particular example, the hosts with alias names wiley,elmer,and galaga are the sender systems and the host with alias name faraday is the receiver system. The senders sends data in full stream mode; each one transmits 131072 bytes as fast as possible for 10 minutes (duration of experiment). For this data transfer TCP is used with a window size of 10 MB. As you can observe, through our script we can change the parameters accordingly to the adopted testbed we want to test. Since in this experiment we were testing a satellite link, we used a big TCP window size (10MB) and we ran the experiment for a longer period of time (600 seconds).


Table 1: Explanation of NetSpec script keywords

KEYWORDS
DESCRIPTION
ALTERNATIVES
parallel
Indicates parallel multiple traffic connections. It can be point-to-multipoint or multipoint-to-point connections. Data flows between the source and receiver of each block simultaneously.
serial
or nothing to indicate single connection.
serial
Indicates serial multiple traffic connections. Data flows between the source and receiver of each block after the previous data flow is completed. (one at a time)
parallel
or nothing to indicate single connection.
cluster
Indicates the beginning of a structured block, where the source and destination end systems will be defined, as well as the various network parameters. If a machine domain name or its IP follows (after ) then the control daemon (nscntrld) will run on that machine. If nothing follows, then the control daemon will run in the machine you are running the NetSpec script.
NONE
test
Specifies where the test daemon (nstetsd) will run. Apparently it specifies the end systems under test. The end system domain name or its IP address can be passed as parameters.
NONE
type=
Indicates in what mode (type) the experiment will run. Fullstream, burst, or queued burst types can passed as parameters.
NONE
full
The test will run on the full stream mode. That means that the end systems will transmit data as fast as possible.
burst, burstq
blocksize=
Indicates the burst size in blocks(bytes).
NONE
duration=
Indicates the duration of your experiment in seconds. Tests in the University of Kansas showed that NetSpec can run successfully for hours.
NONE
period=
Indicates the burst period in microseconds. This is only used in the burst and queued burst modes. In the full stream mode, this parameter is omitted
protocol=
Indicates the transport protocol to be used in the experiment.
NONE
tcp
The TCP protocol is used throughout the experiment.
udp
udp
The UDP protocol is used throughout the experiment.
udp
window=
The TCP window size in bytes to be used in the experiment. When UDP is used, this parameter is omitted
own=
Indicates the local machine (by domain name or IP address) where the test daemon is running within the block. A machine port can be identified as well if desired by the user. Therefore, in the script source block (the block where after "type=", "sink" is not following) this keyword is followed by the transmitter, whereas in the script receiving block (the block where after "type=", "sink" follows) this keyword is followed by the receiver.
NONE
peer=
Indicates the local machine (by domain name or IP address) where the test daemon is running within the block. A machine port can be identified as well if desired by the user. Therefore, in the script source block (the block where after "type=", "sink" is not following) this keyword is followed by the receiver, whereas in the script receiving block (the block where after "type=", "sink" follows) this keyword is followed by the transmitter.
NONE
!!!
KEY-WORDS USED IN THE EMULATED TRAFFIC SCRIPTS
!!!
Keywords
Description
Required Parameters
telnetSessionInterarrival
Interarrival Time for TELNET sessions
lambda
telnetSessionDuration
Duration of a TELNET session
mean, stdDeviation
telnetPacketInterarrival
Interarrival of TELNET packets in a TELNET session
Fixed Model
telnetPacketSize
TELNET Packet size
Fixed Model
ftpSessionInterarrival
Interarrival Time for FTP sessions
lambda
ftpNOfItems
Number of Items transfered in an FTP session
Fixed Model
ftpItemSize
Size of FTP items in an FTP session
Fixed Model
voiceSessionInterarrival
Interarrival Time for Voice sessions
lambda
voiceSessionDuration
Duration of Voice sessions
lambda
videoTeleConferenceFrameSize
Frame Size of a Video Teleconference Session
scale, shape
videoMPEGFrameSize
Frame Size of a Video MPEG Session
sceneLengthMean,
Imean,IstdDeviation,
Pmean, PstdDeviation,
Bmean,BstdDeviation
WWWRequestInterarrival
Interarrival Times for WWW Requests
lambda
WWWItemSize
Size of Items transferred in WWW Request
Fixed Model


|TOP |Introduction to NetSpec| User NetSpec scripts|