Internet Traffic Modeling with TMODEL

tmodel is an application for modeling various types of Internet traffic. There is one executable, tmodel, which always operates as a server (see detailed descriptions for client and server roles in this application). If you specify a configuration file, tmodel will also operate as a client and initiate all traffic modeling sessions.

tmodel heavily uses the TCPLIB software package for generating random numbers based on cumulative distribution functions. The full TCPLIB package and documentation is available off of Sugih Jamin's papers page: http://irl.eecs.umich.edu/jamin/papers/

The HTTP traffic model is based on the work of Bruce A. Mah at UC-Berkeley. His work is available here: http://http.cs.berkeley.edu/~bmah/Software/HttpModel/

Running TMODEL

tmodel can be found in /home/borg/tmodel/ on FreeBSD machines,
/net/buzzard/dirt/borg/tmodel/ or ~borg/tmodel/ on AFS machines.
Underneath this directory, in src, is the latest source code.

Running tmodel is simple:

tmodel [-d] [-p##] [filename]        (Default port = 6789)

The -d option throws the program into a debug mode, with more verbose output.

The -p option allows you to specify a particular port to start the server on. Note that tmodel will always spawn a server (for some traffic models, the client must also have a server ready to accept connections), so be wary of starting multiple instances of tmodel on the same machine. You must specify different ports for them to listen on.

The default port is 6789.

If a configuration filename is specified, tmodel spawns client processes to handle the sessions specified in the file. A detailed discussion of configuration files follows...

Supported traffic models

This bulk traffic model is for TCP. The client asks the server to send buffers of a certain size for a particular duration of time. The server sends these buffers as fast as it can for that duration of time.

HTTP traffic

For http, the client models the actions of a single web surfer, and the server acts as a simple, stateless, file server that simply spits back files of the particular size asked for. This means that all modeling data is taken at the client's side. The modeled quantities are:

consecutivedocs: The number of consecutive documents, or pages, that the surfer will visit for his/her stay at this particular site.

filesperdoc: The number of files contained per document, or page. This simulates graphics, etc., contained in a page for which the surfer's browser must establish additional connections to receive all the data.

primaryrequest: The size of the initial "request" sent to the server.

primaryreply: The size of the first file in a page sent back to the surfer.

secondaryrequest: The size of subsequent "requests" made to the server.

secondaryreply: The size of the subsequent files sent back to the surfer.

thinktime: The length of time a surfer thinks before requesting the next document, or page.

FTP traffic

For ftp, the client models the actions of a single ftp user asking for files from an ftp server. This is basically a simplified version of the http model. The modeled quantities are:

nitems: The number of items requested from a server at any given time. Similar to the filesperdoc quantity for http.

itemsize: Modeled for each item, this is the size of the file to be sent back to the client.

ctlsize: Size of the request packets and other control packets passed between the client and the server.

TELNET traffic

Telnet models a user's actions as he/she is remotely logged into another computer. Since telnet sends single keystrokes to the telnet server on the remote computer, the client simply sends one-byte packets to the server, which responds with varying-length messages. The periodicity of the client requests are modeled with the interarrival and duration quantities; interarrival is the number of seconds between requests, and duration is the length of time to send requests at this interarrival rate. The server samples pktsize, which is the length of the response, every time a request is received.

The configuration file

Sample configuration files are in /home/borg/tmodel/ on the FreeBSD machines (that's /net/buzzard/dirt/borg/tmodel/ or even ~borg/tmodel/ on AFS accounts).

Each line of each client specification is in the form

fieldname:value

Note that no spaces are allowed between the fieldname and the value.
Note also that all client specifications must end with a single "#" on a line by itself.
Furthermore, multiple clients may be spawned from the same clientfile by simply stringing client specifications together, separated by single "#"'s on lines by themselves.
(These are all just the way my parser was hacked together ... there are no comment lines.)

All traffic types can specify the following fields: (fields with a * are required fields)

host*: The target (server) hostname.

port: The target (server) port number. (Default: 6789)

traffic*: The traffic type.

sbuffer: The size buffers to use on each side.

delay: The time (in seconds) after the client has been spawned until the time the traffic simulation begins.

duration: The length of time to run the simulation.

Bulk traffic

Bulk traffic does not define any additional fields.

HTTP traffic

HTTP allows you to also specify:

connection:{multiple,static}: multiple is the way current browsers work: a new connection is created for each file contained in a document. static is for the next generation of browsers: a single connection is maintained. In general, use "multiple". I think "static" may be broken.

interarrival: The exponential mean of the thinktime (in secs) between http sessions. The http model only models a browser's habits on a single website. When the model finishes, we want to start over again (simulate a new user hitting the website). I use "0". This means a new user hits the site as soon as the last one leaves.

FTP traffic

FTP allows you to also specify:

interarrival: The exponential mean of the thinktime between ftp sessions. This is exactly the same as the quantity for HTTP sessions. I have been using "9" just because.

TELNET traffic

TELNET does not define any new fields.

Pointers into the code...

Undoubtedly, someone is going to have to hack this up a bit, especially due to a lack of meaningful data statistics. It should be relatively easy to figure out, though. It's a very linear and mundane design ...

tcpt.h

Defines all globals and constants, including connection types, mode variables, and buffer sizes. Also stubs functions.

This is the main module (apologies to ttcp, I was quite unoriginal when I began this app....), which contains a few useful library routines, and the code to parse the client configuration file.

main always forks a server process, and if a client file is specified, calls...

parse_client_file, which chugs through the file and spawns a client process for each entry.

This module contains all the necessary client-side code, including routines to connect to servers and all the linear code for each of the modeled traffic types. Traffic types are by traffic name, and follow the outline above.

One item of note about telnet: the telnet_timer_handler() routine does most of the dirty work, and is called by telnet(). All timing is done using usleep(), so there aren't any signals or complicated timers to deal with, despite the name telnet_timer_handler().

Yes, all the server-side code.

handler() is the main routine that sits and waits for connections. This routine calls the handle_* routines as it determines what type of traffic is being run on this connection. Note that for many traffic types, the server establishes its own unique connection to the client for the response-stream. Typically, this is handled by the sink routine. sink can probably be greatly modified for receiver-side statistics (hint hint).

The other files are predominantly all tcplib files. For each new traffic type, tcplib generates two files:

traffic_type.h: this contains data structures of the actual cumulative distribution functions for each of the modeled data types.

traffic_type.c: the stubs for each of the modeled values. This file basically wraps the tcplib() routine, passing in a cdf defined in the corresponding traffic_type.h file.

The tcplib documentation contains detailed instructions for producing new libraries for new traffic types.

Good data for http connections can be obtained from right within the http() and the handle_http() routines.

Good data for telnet and ftp is probably better obtained within the handle_sink() routine.