The host entries are used to configure the protocol stacks of the hosts attached to the internetwork. The actions a host takes when the simulator is run is determined by its protocol stack, especially by the ``application-level'' protocol(s) (i.e., megtest and/or traffic) located at the top of the stack.
The only difference between a simulated host's protocol graph in x-sim and a real host's protocol graph in the x-kernel is that they specified through different means. In the x-kernel , the graph.comp file configures the protocol graph. In x-sim , the graph.comp file is used only to determine which protocols to include in the simulator executable; the relationships between the protocols are ignored. The simulator uses the host entries in the xsim.data file to configure protocol graphs for each host. Note that although we have created special, heavily-instrumented, versions of many protocols, any x-kernel protocol can be included in the simulator.
The syntax of a host entry is:
host <name>; protocols = <hlp> <llp> <llp> ... , <hlp> <llp> <llp> ... , ... ; args = <arg> <arg> ... ; pargs <protocol instance> = <arg> <arg> ... ; pargs <protocol instance> = <arg> <arg> ... ; ...
The name given in the host line must match the name given in the net entry.
The protocols line configures the protocol stack running on the simulated host. It consists of groups of protocols separated by commas. The first protocol in a group ( hlp) is configured over the remaining protocols ( llp) in the same group.
There are a couple of points to be aware of when building a host's protocol graph. First, all protocol graphs in the simulator must contain the special sim protocol on the bottom. Second, an application-level protocol like megtest or traffic must be placed at the top of the stack, otherwise the hosts will not have any reason to send data to each other
Figure 4: Example protocol graph
The following sections contain more information about these, and other, special simulator protocols. Figure 4 shows a typical protocol graph. This graph is represented in the
protocol line of a host entry as shown below.
protocols = megtest rtcp, rtcp ip, ip vnet, vnet eth arp, arp eth,
eth ethd, ethd sim;
Many protocols accept configuration parameters; the args line lists those parameters that all the protocols interpret. Each protocol instance, at initialization, scans through the args line to see if it contains any arguments that the protocol understands.
In addition to, or in place of, the args line, there can occur one or more pargs lines ( pargs stands for ``protocol args''). A pargs line allows you to an specify argument list for a specific protocol instance that appeared in the protocols line.
An argument listed on the args line is interpreted by all protocol instances that understand the argument. However, a
pargs entry becomes necessary when multiple instances of a protocol are configured on a host, and each instance must be given different parameters. For example, assume that a host's protocol stack contains two instances of the Ethernet driver, named ethd/1 and
ethd/2. An -ethdDelay argument meant exclusively for the ethd/2 instance may be specified as:
pargs ethd/2 = -ethdDelay=10us;
The following subsections list, by protocol, arguments that can be included on the args and pargs lines.
sim is a protocol that lies at the bottom of the protocol graph. It simulates the networks and routers that make up an internetwork. Passing a message to the sim protocol is equivalent to putting it onto a network's physical wire. The
sim protocol then simulates the message's journey through the modeled network until it reaches a protocol subgraph representing the final destination host, at which time sim passes the message up to that host's protocol graph. sim also replies to ARP and RARP requests made by hosts. Special protocols, called driver protocols, are used between standard x-kernel protocols and the sim protocol. There are no arguments used with the sim protocol.
The ethd protocol is the ``device driver'' that a host uses to connect to either an Ethernet or a point-to-point link. The following arguments for ethd may be specified on an args or
pargs line.
-ethdDelay=<integer>
Used to simulate the time it takes, in microseconds, for a host to process a packet. During the time period specified, the host cannot accept or process any other packets. If this option is not specified, hosts are assumed to be infinitely fast.
-ethdDelayRange=<integer>
A random number of microseconds is added to each delay period specified by -ethdDelay. If the argument given is x, then the interval of the modification is between -x and x. Note that the range specified should be less than or equal to the delay specified using -ethdDelay.
-ethdQueue=<integer>
Specifies the maximum number of messages that can be queued for transmission by ETHD. This is useful when using hosts running IP as routers; it is the only way to specify the maximum queue size for the router outports.
-ethdTrace=<integer>[:<integer>]
Indicates that the Ethernet driver protocol should save trace information (e.g., opens, sends, drops) and specifies the amounts of memory and disk space that may be used for this purpose. The first integer argument specifies the size, in trace entries (about 8 bytes each), of the circular buffer used to hold trace information in memory. If no colon and second argument is specified, this number also represents the maximum size of the trace file. The second argument specifies the maximum number of memory buffers that the disk file may contain. See the explanation of shortTrace in Section 3.4.1 for an example.
-ethdTraceIn
In conjunction with -ethdTrace, traces the average number of bytes/second arriving on the interface associated with the ethd driver.
-ethdTraceOut
In conjunction with -ethdTrace, traces the average number of bytes/second sent on the interface associated with ethd
An adaptation of BSD Lite's Big Window TCP. Big Window TCP is an implementation of a TCP extension that allows send windows greater than 64KB in size. See RFC 1323 for more information on Big Window TCP. The following arguments for btcp may be specified on an args or pargs line.
-tcpAcknow
If this option is specified, the protocol acknowledges every segment. The default is to send an ACK for every 2nd segment, or upon expiration of the fast timeout.
-tcpSlowstart=<integer>
Specifies the size of the window, in segments, at the beginning of slow start. The default is 1. This option is included for experimental purposes.
-tcpTimer=<integer>
Specifies a delay, in microseconds, before starting the TCP fast and slow timeouts. Without some timer delay, all hosts in a simulation will experience timeouts simultaneously -- this could lead to strange simulation results. The preferred alternative to manually specifying a different delay for each host is to use -tcpTimerAuto.
-tcpTimerAuto
Instructs the simulator to stagger the start delay for the timers on each host. If the duration of a timer is t, and there are n hosts, the hosts' timers are started at intervals of t/n milliseconds. For example, the fast timeout fires at intervals of 200 ms. If there were four hosts, their fast timeouts would be started after delays of 0, 50, 100, and 150 ms. Thus, every timer is given a unique start delay.
-tcpTrace=<integer>[:<integer>]
Trace events of importance to TCP, such as the transmission of a segment, the size of the send window, and the firing of a timeout. The function of the arguments is the same as with the
-ethdTrace option. (See Section 3.5.2.)
Historically, TCP Reno superceded TCP Tahoe. Reno differs from Tahoe in that the it ACKs every other packet and uses the Fast Recovery mechanism. The arguments used with rtcp are identical to those used with btcp arguments.
-tcpAcknow -tcpSlowstart=<integer> -tcpTimer=<integer> -tcpTimerAuto -tcpTrace=<integer>[:<integer>]
See Section 3.5.3 for information on these options.
The arguments used with ttcp are identical to those used with btcp, with the exception that -tcpAcknow has no meaning. This is because ttcp sends an ACK for every packet it receives.
-tcpSlowstart=<integer> -tcpTimer=<integer> -tcpTimerAuto -tcpTrace=<integer>[:<integer>]
See Section 3.5.3 for information on these options.
TCP Vegas is a version of TCP, developed at the University of Arizona, that uses a congestion avoidance strategy to decrease losses and improve throughput over TCP Reno. Arguments common to the other TCPs may be used on the args and pargs lines.
-tcpAcknow -tcpSlowstart=<integer> -tcpTimer=<integer> -tcpTimerAuto -tcpTrace=<integer>[:<integer>]
See Section 3.5.3 for information on these options. In addition, several arguments are specific to TCP Vegas.
-tcpTop=<integer>
The 
parameter used by TCP Vegas to specify the minimum number
of extra router buffers to use when not in slow start. The default is
1.
-tcpBot=<integer>
The 
parameter used by TCP Vegas to specify the maximum number
of extra router buffers to use when not in slow start. The default is
3.
-tcpExp=<integer>
Specifies the maximum number of extra router buffers to use in slow start. The default is 1.
-tcpFlags=[e|E][s|S][c|C][p|P]
This option is followed by a string of up to four letters, each of which enables (lower case) or disables (upper case) the corresopnding vtcp option.
Both congestion avoidance options are enabled by default, and the others are disabled. Thus, specifying p as an argument is the same as eScp.
megtest is an application-level protocol, that is, it sits at the top of the protocol stack and determines the actions taken by a host during a simulation. A megtest client opens a TCP connection to a megtest server and streams data (default is one megabyte) to the server. The megtest protocol allows us to measure and compare the throughput of the various TCP protocols. The following arguments for megtest may be specified on an args or pargs line.
-buf=<integer>
Specifies the size, in kilobytes, of the TCP send and receive buffers.
-db=<filename>
Specifies the filename in which to print general information about the run. If this option is not specified, this information is not saved.
-dbId=<integer>
After the test, prints the line id: <integer> in the file specified by the -db option.
-dbStr=<string>
Specifies a string to print in the file specified by the -db option after the run has ended. This option is used to print descriptive information about the run, so that multiple runs can be output to the same file and later identified. For example, if one of the important characteristics of a simulation is that all routers use 30 buffers, then the argument, -dbStr=rbufs:30 would print the line rbufs:30 in the output file immediately following the trace information printed by the run. You can have up to 10 different -dbStr per host.
-delay=<integer>[unit]
The delay in (simulated) time units before the test starts. The optional unit can be one of us (microseconds), ms (milliseconds), or s (seconds). The default unit is milliseconds. When running megtest in the presence of background traffic, a delay of a few seconds should be specified in order to give the background connections a chance to stabilize.
-killTraffic
If given as an argument to a single host, after the megtest on this host is done, the traffic is killed and the simulation stops. This option is usually used on the command line after
-all, where it signifies that after all megtest protocols have completed their streaming, all traffic processes are killed and the simulation stops.
-len=<integer>
Sets the amount of data, in kilobytes, to be transferred by the test. The default is 1024, that is, 1MB.
-megTime=<integer>[unit]
Stop the megtest after it has been allowed to run for the specified number of time units, even if the transfer has not completed. The optional unit can be us (microseconds), ms (milliseconds), or s (seconds). The default unit is seconds.
-reset=<integer>
Resets TCP trace information after the specified number of seconds. Often, data about transfers is only of interest after the traffic has had a chance to stabilize, which usually takes a few (simulated) seconds.
-serverPort=<integer>
Used if a single host is running multiple megtest servers, where each server instance must be assigned a port to listen on. A megtest client specifies which server on the host it wants to talk to, by specifying the appropriate port in the client's
-serverPort option.
-showTime
If this option is given, every so often the megtest process prints the elapsed time.
-thresh=<integer>
Specifies the initial threshold variable for TCP's slow start, in 1KB units. The default is one half of the buffer size specified by the -buf option.
Like megtest, traffic is an application-level protocol. The traffic protocol simulates typical Internet traffic based on tcplib---a library that models Internet traffic sources that is based on empirical data collected at different Internet gateways.
traffic starts conversations with interarrival times given by an exponential distribution. Each conversation can be of type TELNET, FTP, NNTP or SMTP, and each expects a set of parameters. For example, FTP conversations are parameterized by the number of items to transmit, control segment sizes, and the individual item sizes. All of these parameters are obtained from tcplib and are based on probability distributions obtained from real traffic traces. Finally, each of these conversations runs on top of its own TCP connection.
The startup distribution of traffic conversations is determined solely by the initial seeds given to the traffic protocol, and not by the lower protocols. Therefore, two traffic simulations started with the same seeds will start the same tcplib conversations at the same times. This is important for reproducing experiments, or for guaranteeing that observed behavior difference between protocols is not due to different traffic patterns.
By default, traffic hosts are servers and not clients. In other words, unless otherwise specified, a traffic host will respond to requests to open connections but will not initiate connections. Use the -hosts or -rhosts options to create traffic clients. A traffic host can be both a client and a server.
The following arguments for the traffic protocol may be specified on an args or pargs line.
-cit=<interval>
Specifies the average connection interarrival time (CIT) to be used at equilibrium. This time is used by the traffic protocol to decide when to open new connections; the traffic protocol should space new connections by this interval, on average. Note that a lower CIT means that connections are opened more frequently, leading to a greater overall number of open connections. See the
-begcit, -begdur, and -begint options for opening connections at simulator startup. See Figure 5 for a diagram that illustrates the relationship among these parameters.
Figure 5: Interaction of CIT Parameters
-begcit=<integer>
Since there are no open connections at the beginning of a simulation, it is often desirable to open a lot of connections at once; setting this variable to a number lower than that used with the -cit option will allow connections to be opened more quickly. This number is used as the connection interarrival time until the interval specified with -begint has elapsed.
-begdur=<integer>
Specifies the number of seconds to elapse after starting a simulation before the number specified by -cit is used as the connection interarrival time. Between the end of the time specified by
-begint and -begdur, the CIT grows linearly toward the level specified by the -cit option.
-begint=<integer>
Specifies the number of seconds that the CIT specified by
-begcit should be used, before the CIT is allowed to grow linearly towards that specified with the -cit option.
-begkeep=<integer>
Rather than creating a new thread for each new traffic connection and destroying them after the connection closes, the
traffic protocol caches the threads for later use. The number of threads in the cache will be equal to the maximum number of connections that have been open simultaneously. Since a large number of connections may be opened at the beginning of the simulation by the parameters described above, the cache may contain more threads than will be needed by the rest of the simulation. This option allows excess threads to be freed from the cache. It specifies that the simulator should only keep the specified number of threads in cache; if later it needs more, it will reallocate them. This is an optimization feature---it may improve the running time of a simulation, but will not affect its results in any way. The default value is 100.
-db= -dbStr=
These options are the same as specified in Section 3.5.7.
-ftpBufSize=<integer>
Sets the send buffer size, in kilobytes, for FTP connections generated by the traffic protocol. The default is 20, that is, 20KB.
-hold=[f][n][s][t]
Tells the traffic host never to start a particular kind of connection. The arguments correspond to the first letters of the types of tcplib connections: f is FTP, n is NNTP, s is SMTP, and t is TELNET. Thus -hold=ft specifies that the traffic host should never begin an FTP or a TELNET connection.
-hosts=<integer> <IP addr 1> <IP addr 2> ...
Specifies that this host will be a traffic client, and lists the servers with which the client will randomly establish connections. The first argument is the number of servers, and the remaining arguments specify the IP addresses of the traffic servers.
-otherBufSize=<integer>
Sets the send buffer size, in kilobytes, for non-FTP transfers. The default is 10, that is 10KB.
-reset=<integer>
Resets the information accumulated about traffic transfers after the specified number of seconds. Often, data about transfers is only of interest after the traffic has had a chance to stabilize, which usually takes a few (simulated) seconds.
-rhosts=<integer>
Provides an alternative to the -hosts option when the user does not want to specify the IP addresses of the traffic servers. Like -hosts, this option specifies that the host is a client. At startup, the simulator randomly picks the specified number of hosts out of the pool of traffic hosts, and the client will establish connections to only this subset of hosts. Note that the selection occurs from all traffic hosts, even if they are not servers. Therefore, it is recommended that all hosts are designated as servers if this option is used.
-s
Specifies that the host is a server. This is the default. A host can be both a client and a server.
-s0
Specifies that the host is not a server.
-seed=<integer>
Specifies a seed to be used by that host to begin the random number function that determines the distribution of traffic connections. Usually, this option is not used. Instead, a global seed is specified on the command line, and this seed is automatically modified by the host name to produce one that is unique for each simulated host. See the -seed command-line option.
-showTraffic
When the simulation ends, prints some summary information about the traffic for that simulation; this is the default if there are less than 10 traffic hosts. Otherwise, this option must be specified for each host from which the summary is desired.
-trafficTime=<integer>[unit]
Stops the traffic test after it has been allowed to run for the specified number of time units. The optional unit can be
us (microseconds), ms (milliseconds), or s (seconds). The default unit is seconds.
-trafficTrace=<integer>[:<integer]
Saves trace information generated by the traffic protocols. The meanings of the integer arguments are the same as those of the -ethdTrace option. (See Section 3.5.2.)