for each communication state. This enables the
definition of an upper limit on the time spent in
the communication state. The impatience factor
is formulated as a condition of θi,j(x) in (1), and
its randomness is defined in the stochastic part
of the source model.
2.2 Model Template Examples
This section demonstrates the applicability and
the flexibility of the modelling framework by
describing the model templates that have been
developed using the GenSyn framework. First
the interface modules currently available are
described, followed by two examples of model
templates that imitate web and VoIP user be-
haviours and a model that combines these. The
interface modules handle the actual communi-
cation through the IP network.
The framework of GenSyn is not limited to these
models, and can easily describe other state ori-
ented models, or change the model parameters.
Finally, Section 2.2.3 includes an example of a
packet trace collected at a single point in a test
network viewing packets generated from several
GenSyn processes running a mixture of FTP and
voice models.
2.2.1 Available Interface Modules
To make it easy to build new models and create
realistic traffic mixtures a set of different inter-
face modules is developed – including e.g. a
module for downloading and reading web pages,
a module for sending a deterministic stream of
UDP, and a module for sending a stream of UDP
packets determined by the content of a trace file,
e.g. an mpeg coded video stream. This section
describes some of the details in these modules.
2.2.1.1 Web Module – a Web Browser
The web module is a simplistic web-browser
that downloads web pages from actual web
servers. The browser downloads the source file
of the web page, parses this, and downloads the
embedded objects (e.g. images and java applets)
identified on this page. These are also down-
loaded, in parallel with each other and in parallel
with the download of the web source file.
The url addresses are randomly chosen from a list
of 2500 addresses from all over the world. This
list can easily be changed. For example, as an
option, GenSyn offers to dynamically check and
update the url list as the generator is running and
new pages are visited. This is done by inclusion
of some, or all, of the href addresses found when
parsing through the source file of a web page.
The download time per web page is constrained
by the transport protocol and the network and
server conditions. In addition, GenSyn allows
the user to set a time-out parameter, impatience
time, that sets the maximum limit of the down-
load time.
2.2.1.2 Ftp Module – Download a File
The FTP interface module uses http to download
a file. The file can be downloaded from any
machine that is set up as a web server and read
directly into the memory on the receiving
machine, i.e. the machine that is hosting the
GenSyn process running the FTP client. In con-
trast to the web interface module in Section
2.2.1.1, see also [Heeg00], the FTP module adds
very little to the download time due to process-
ing in GenSyn, and hence the download time is
constrained by the server responses and transfer
delays. Similar to the web module, the impa-
tience timeis also a parameter in the FTP mod-
ule. See Section 4.2 for discussion of GenSyn
constraints.
The pointer to the files that can be downloaded
by the FTP interface module are given as url
addresses in a separate parameter list as input.
This list is in a text file that can easily be
changed and hence the user of GenSyn can cre-
ate any empirical file distribution. As an exam-
ple, the FTP client in the experiment in this
paper randomly selects its files from the file size
distribution (i.e. notthe IP packet distribution)
depicted in Figure 5 with an average size of
154 kbytes (adopted from [Dan92]).
2.2.1.3 Mpeg Module – Sending UDP
Packets According to Trace Data
The mpeg module was developed to have a mod-
ule that can read a stream of numbers represent-
ing a variable bitrate coded video trace, convert
to udp packets and send it to a given address. In
general this module can take any file that con-
Algorithm 2: Update the state vector when
the next event is an event in WC
(i) Sample the time Tto next event in WSas
described in step (i) of Algorithm 1.
(ii) If (∃k∈WC) ∧(Tk< T), i.e. a communica-
tion stream is closed before the time T
elapses, then replace step (iii) of Algorithm
1 with the following:
(iii) The next event takes place in state kin
WCwhere kis the first stream closed, i.e.
Step (iv) and (v) are the same steps as in
Algorithm 1 except that the pi,jis given as
parameters because they cannot be derived
from the conditional rate qi,j(x) which is now
either ∞or 0.
k=⎧⎨ii∈ΩC∧(Ti=minj∈ΩC(Tj))
⎩