Provided by: ns2_2.35+dfsg-3build1_amd64 bug

NAME

       ns - network simulator (version 2)

SYNOPSIS

       ns [ file [ arg arg ...  ] ]

DESCRIPTION

       ns is an event-driven network simulator.  An extensible simulation engine is implemented in C++ that uses
       MIT's Object Tool Command Language, OTcl  (an  object  oriented  version  of  Tcl)  as  the  command  and
       configuration  interface.   A  previous  version of the simulator i.e. ns version 1 used the Tool Command
       Language, Tcl as the configuration language.  The  current  version  still  supports  simulation  scripts
       written in Tcl meant for the ns version 1 simulator.

       This  manual  page documents some of the interfaces for ns.  For much more complete documentation, please
       see "ns Notes and Documentation" [13], available in the distribution and on the web.

       The simulator is invoked via the ns interpreter, an extension of the vanilla  otclsh  command  shell.   A
       simulation  is  defined by a OTcl script.  The scripts use the Simulator Class as the principal interface
       to the simulation engine.  Using the methods defined in  this  class,  a  network  topology  is  defined,
       traffic  sources  and  sinks are configured, the simulation is invoked, and the statistics are collected.
       By building upon a fully functional language, arbitrary actions can be programmed into the configuration.

       The first step in the simulation is to acquire an instance of the Simulator class.  Instances of  objects
       in classes are created and destroyed in ns using the new and delete methods.  For example, an instance of
       the Simulator object is created by the following command:

            e.g. set ns [new Simulator]

       A network topology is realized using three primitive building blocks:  nodes,  links,  and  agents.   The
       Simulator  class  has methods to create/ configure each of these building blocks.  Nodes are created with
       the node Simulator method that automatically assigns an unique address to each node.  Links  are  created
       between  nodes  to  form  a  network  topology  with the simplex-link and duplex-link methods that set up
       unidirectional and bidirectional links respectively.  Agents are the  objects  that  actively  drive  the
       simulation.   Agents  can be thought of as the processes and/or transport entities that run on nodes that
       may be end hosts or routers.  Traffic sources and sinks, dynamic routing modules and the various protocol
       modules are all examples of agents.  Agents are created by instantiating objects in the subclass of class
       Agent i.e., Agent/type where type specifies the nature of the agent.  For example, a TCP agent is created
       using the command:

            set tcp [new Agent/TCP]

       Once  the  agents  are  created, they are attached to nodes with the attach-agent Simulator method.  Each
       agent is automatically assigned a port number unique across all agents on a given node  (analogous  to  a
       tcp or udp port).  Some types of agents may have sources attached to them while others may generate their
       own data.  For example, you can attach ``ftp'' and ``telnet'' sources to ``tcp''  agents  but  ``constant
       bit-rate''  agents  generate  their  own  data.  Applications are attached to agents using the attach-app
       method.

       Each object has some configuration parameters associated with it that  can  be  modified.   Configuration
       parameters  are  instance  variables  of  the object.  These parameters are initialized during startup to
       default values that can simply be read from the instance variables of the object.  For example, $tcp  set
       window_  returns  the  default window size for the tcp object.  The default values for that object can be
       explicitly overridden by simple assignment either before a simulation begins, or dynamically,  while  the
       simulation  is  in  progress.  For example the window-size for a particular TCP session can be changed in
       the following manner.

            $tcp set window_ 25

       The default values for the configuration parameters of all the class  objects  subsequently  created  can
       also be changed by simple assignment.  For example, we can say

            Agent/TCP set window_ 30

       to make all future tcp agent creations default to a window size of 30.

       Events  are  scheduled  in  ns using the at Simulator method that allows OTcl procedures to be invoked at
       arbitrary points in simulation time.  These OTcl callbacks provide a  flexible  simulation  mechanism  --
       they  can  be  used to start or stop sources, dump statistics, instantiate link failures, reconfigure the
       network topology etc.  The simulation is started via the run method and continues until there are no more
       events  to  be  processed.   At this time, the original invocation of the run command returns and the Tcl
       script can exit or invoke another simulation run  after  possible  reconfiguration.   Alternatively,  the
       simulation  can  be  prematurely  halted by invoking the stop command or by exiting the script with Tcl's
       standard exit command.

       Packets are forwarded along the shortest path route from a source to a destination,  where  the  distance
       metric is the sum of costs of the links traversed from the source to the destination.  The cost of a link
       is 1 by default; the distance metric is simply the hop count in this case.  The cost of  a  link  can  be
       changed  with  the  cost Simulator method.  A static topology model is used as the default in ns in which
       the states of nodes/links do not change during the course of a simulation.   Network  Dynamics  could  be
       specified  using  methods  described in NETWORK DYNAMICS METHODS section.  Also static unicast routing is
       the default in which the routes are pre-computed over the entire topology  once  prior  to  starting  the
       simulation.   Methods  to enable and configure dynamic unicast and multicast routing are described in the
       UNICAST ROUTING METHODS and MULTICAST ROUTING METHODS sections respectively.

NS COMMANDS

       This section describes the basic commands to create the building blocks of the simulation (i.e. the node,
       link and agent objects) and to run the simulation.

       The  first step in running a simulation as stated before is to acquire an instance of the Simulator class
       that has methods to configure and run the simulation.  Throughout this section the object  variable  name
       $ns is used to imply a Simulator object.

       $ns node
              Create a new node object and return a handle to it.

       $ns all-nodes-list
              Returns a list of all the node objects defined in the simulation.

       $ns simplex-link node1 node2 bw delay type
              Create  a new unidirectional link between node1 and node2 with bandwidth bw in bits per second and
              link propagation delay delay in seconds.  node1 and node2 must have already been created with  the
              node  method.  bw and delay default to 1.5 Mbits/sec and 100 ms respectively.  The defaults can be
              changed by modifying the relevant configuration parameters of the DelayLink Object (see  DELAYLINK
              OBJECTS  section).   node1  and  node2  must  have already been created with the node method.  The
              queuing discipline of the link is specified by type, which may be DropTail,  FQ,  SFQ,  DRR,  RED,
              CBQ,  or CBQ/WRR.  A DropTail link is a simple FIFO queue which drops the last packet in the queue
              when the queue overflows.  A FQ link is for Fair Queuing (for details see [?]).  A SFQ link is for
              Stochastic  Fair  Queuing (for details see [?]).  A DRR link is for deficit round robin scheduling
              (for details see [9]).  A RED link is a random-early drop queue (for details see [2]).  A CBQ link
              is  for  class-based queuing using a packet-by-packet round-robin scheduler (for details see [3]).
              A CBQ/WRR link is for class-based queuing with a weighted round  robin  scheduler.   If  multicast
              routing  is  used  links  with  interface  labels are required.  Such links are created by setting
              Simulator NumberInterfaces_ variable to 1.  All the subsequently created links will have interface
              labels.   To  disable  creation  of  interfaces  simply  reset NumberInterfaces_ to 0 (this is the
              default).

       $ns duplex-link node1 node2 bw delay type
              Create a new bidirectional link between node1 and node2 with bandwidth bw in bits per  second  and
              link  propagation delay delay in seconds.  node1 and node2 must have already been created with the
              node method.  bw and delay default to 1.5 Mbits/sec and 100 ms respectively.  The defaults can  be
              changed  by modifying the relevant configuration parameters of the DelayLink Object (see DELAYLINK
              OBJECTS section).  The queuing discipline of the link is specified by type, which may be DropTail,
              FQ  SFQ,  DRR,  RED, CBQ, or CBQ/WRR.  A DropTail link is a simple FIFO queue which drops the last
              packet in the queue when the queue overflows.  A FQ link is for  Fair  Queuing  (for  details  see
              [?]).  A SFQ link is for Stochastic Fair Queuing (for details see [?]).  A DRR link is for deficit
              round robin scheduling (for details see [9]).  A RED  link  is  a  random-early  drop  queue  (for
              details  see  [2]).   A  CBQ  link is for class-based queuing using a packet-by-packet round-robin
              scheduler (for details see [3]).  A CBQ/WRR link is for class-based queuing with a weighted  round
              robin  scheduler.   If  multicast  routing is used links with interface labels are required.  Such
              links are created by setting Simulator NumberInterfaces_ variable  to  1.   All  the  subsequently
              created  links  will  have  interface  labels.   To  disable  creation  of interfaces simply reset
              NumberInterfaces_ to 0 (this is the default).

       $ns link node1 node2
              Returns a reference to the link connecting nodes node1 and node2.  This is useful for setting link
              configuration parameters and to invoke tracing methods (see LINK OBJECTS section).

       $ns queue-limit node1 node2 queue-limit
              Set  the  maximum  number of packets that can be queued on the link in the direction from node1 to
              node2 to queue-limit.  The link between node1 and node2 should have already been created.

       $ns delay node1 node2 time-interval
              Set the latency of the link in the direction from node1 to node2 to  time-interval  seconds.   The
              link between node1 and node2 should have already been created.

       $ns cost  node1 node2 cost-val
              Assign  the  cost cost-val to the link between nodes node1 and node2.  The costs assigned to links
              are used in unicast route computations.  All the links default to a cost of 1.

       $ns multi-link node-list bw delay type
              Connects the nodes specified in node-list by a mesh of duplex links (to simulate a broadcast  LAN)
              with  bandwidth bw in bits per second and link propagation delay delay in seconds.  node-list is a
              list of node object handles that have already been created with the node  method.   bw  and  delay
              default  to  1.5  Mbits/sec and 100 ms respectively.  The defaults can be changed by modifying the
              relevant configuration parameters of the DelayLink Object (see DELAYLINK  OBJECTS  section).   The
              queuing discipline of the link is specified by type, which may be DropTail, FQ SFQ, DRR, RED, CBQ,
              or CBQ/WRR.  A DropTail link is a simple FIFO queue which drops the last packet in the queue  when
              the  queue  overflows.   A  FQ  link is for Fair Queuing (for details see [?]).  A SFQ link is for
              Stochastic Fair Queuing (for details see [?]).  A DRR link is for deficit round  robin  scheduling
              (for details see [9]).  A RED link is a random-early drop queue (for details see [2]).  A CBQ link
              is for class-based queuing using a packet-by-packet round-robin scheduler (for details  see  [3]).
              A CBQ/WRR link is for class-based queuing with a weighted round robin scheduler.

       $ns multi-link-of-interfaces node-list bw delay type
              Connects the nodes specified in node-list by a mesh of duplex links with interfaces (to simulate a
              broadcast LAN) with bandwidth bw in bits per second and link propagation delay delay  in  seconds.
              node-list  is  a  list of node object handles that have already been created with the node method.
              bw and delay default to 1.5 Mbits/sec and 100 ms respectively.  The defaults  can  be  changed  by
              modifying  the  relevant  configuration  parameters of the DelayLink Object (see DELAYLINK OBJECTS
              section).  The queuing discipline of the link is specified by type, which may be DropTail, FQ SFQ,
              DRR,  RED, CBQ, or CBQ/WRR.  A DropTail link is a simple FIFO queue which drops the last packet in
              the queue when the queue overflows.  A FQ link is for Fair Queuing (for details see [?]).   A  SFQ
              link  is for Stochastic Fair Queuing (for details see [?]).  A DRR link is for deficit round robin
              scheduling (for details see [9]).  A RED link is a random-early drop queue (for details see  [2]).
              A  CBQ link is for class-based queuing using a packet-by-packet round-robin scheduler (for details
              see [3]).  A CBQ/WRR link is for class-based queuing with a weighted round robin scheduler.

       new Agent/type
              Create an Agent of type type which may be:
                Null                  - Traffic Sink
                LossMonitor           - Traffic Sink that monitors loss parameters
                TCP                   - BSD Tahoe TCP
                TCP/FullTcp           - Full Reno TCP with two-way connections [11]
                TCP/Reno              - BSD Reno TCP
                TCP/Newreno           - a modified version of BSD Reno TCP
                TCP/Vegas             - Vegas TCP (from U. Arizonia via USC)
                TCP/Sack1             - BSD Reno TCP with selective ACKs
                TCP/Fack              - BSD Reno TCP with forward ACKs
                TCPSink               - standard TCP sink
                TCPSink/DelAck        - TCP sink that generates delayed ACKs
                TCPSink/Sack1         - TCP sink that generates selective ACKs
                TCPSink/Sack1/DelAck  - delayed-ack TCP sink with selective ACKs
                UDP                   - UDP Transport
                RTP                   - RTP agent
                Session/RTP           -
                RTCP                  - RTCP agent
                IVS/Source            -
                IVS/Receiver          -
                SRM                   -
              The methods, configuration parameters and the  relevant  state  variables  associated  with  these
              objects  are  discussed in detail in later sections.  Note that some agents e.g. TCP or SRM do not
              generate their own data.  Such agents need sources attached to them to generate data (see  attach-
              source and attach-traffic methods in AGENT OBJECTS section).

       $ns attach-agent node agent
              Attach  the  agent  object  agent  to  node.   The agent and node objects should have already been
              created.

       $ns detach-agent node agent
              Detach the agent object agent from node.

       $ns connect src dst
              Establish a two-way connection between the agent src and the agent dst.  Returns the handle to src
              agent.   A helper method has been defined to facilitate creating and attaching an agent to each of
              two nodes and establishing a two-way connection between them.  (see BUILTINS section).

       $ns use-scheduler type
              Use an event scheduler of type type in the simulations.  type is  one  of  List,  Heap,  Calendar,
              RealTime.  The List scheduler is the default.  A Heap scheduler uses a heap for event queueing.  A
              Calendar scheduler uses a calendar queue to keep track of events.  RealTime scheduler is  used  in
              emulation mode when the simulator interacts with an external agent.

       $ns at time procedure
              Evaluate procedure at simulation time time.  The procedure could be a globally accessible function
              (proc) or an object method (instproc).  This command can  be  used  to  start  and  stop  sources,
              dynamically  reconfigure  the  simulator, dump statistics at specified intervals, etc.  Returns an
              event id.

       $ns cancel eid
              Remove the event specified by the event id eid from the event queue.

       $ns now
              Return the current simulation time.

       $ns gen-map
              Walks through the simulation topology and lists all the objects that have been created and the way
              they are hooked up to each other.  This is useful to debug simulation scripts.

       ns-version
              Return  a  string identifying the version of ns currently running.  This method is executed in the
              global context by the interpreter.

       ns-random [ seed ]
              If seed is not present, return a pseudo-random integer between 0 and 2^31-1.  Otherwise, seed  the
              pseudo-random  number  generator  with  seed  and  return  the seed used.  If seed is 0, choose an
              initial seed heuristically (which varies on successive invocations).  This method is  executed  in
              the global context by the interpreter.

       Ns has other facilities for random number generation; please see documentation for details [13].

OBJECT HIERARCHY

       A  brief description of the object hierarchy in ns is presented in this section.  This description is not
       intended to be complete.  It has been provided to depict how the  methods  and  configuration  parameters
       associated  with  the  various  objects  are  inherited.   For  more complete information see "ns notes &
       documentation" and the automatically generated class library information on the ns web page.

       Objects are associated with configuration parameters that can be dynamically set and queried,  and  state
       variables  that  can  be  queried  (usually  modified  only when the state variables need to be reset for
       another simulation run).

       Configuration parameters represent simulation  parameters  that  are  usually  fixed  during  the  entire
       simulation (like a link bandwidth), but can be changed dynamically if desired.  State variables represent
       values that are specific to a given object and that object's implementation.

       The following diagram depicts a portion the object hierarchy:
           Simulator
                 MultiSim
           Node
           Link
                 SimpleLink
                      CBQLink
                 DummyLink
           DelayLink
           Queue
                 DropTail
                 FQ
                 SFQ
                 DRR
                 RED
                 CBQ
                 CBQ/WRR
           QueueMonitor
                 ED
                      Flowmon
                      Flow
           rtObject
           RouteLogic
           Agent
                 rtProto
                      Static
                      Session
                      DV
                      Direct
                 Null
                 LossMonitor
                 TCP
                      FullTcp
                      Reno
                      Newreno
                      Sack1
                      Fack
                 TCPSink
                      DelAck
                      Sack1
                          DelAck
                 UDP
                 RTP
                 RTCP
                 IVS
                      Source
                      Receiver
                 SRM
                 Session
                      RTP [how is this diff from Agent/CBR/RTP]
           Appplication
                 FTP
                 Telnet
                 Traffic
                      Expoo
                      Pareto
                      CBR
                      Trace
           Integrator
           Samples

       For a complete, automatically generated, object hierarchy, see the link "class hierarchy"  (which  points
       to  http://www-sop.inria.fr/rodeo/personnel/Antoine.Clerget/ns/) on the ns web pages.  (Thanks to Antoine
       Clerget for maintaining this!)

       For example, any method that is supported by a TCP agent is also supported by a Reno or  a  Sack1  agent.
       Default  configuration  parameters  are also inherited.  For example, $tcp set window_ 20 where $tcp is a
       TCP agent defines the default TCP window size for both TCP and Reno objects.

OBJECT METHODS

       The following sections document the methods, configuration parameters and state variables associated with
       the  various  objects as well as those to enable Network dynamics, Unicast routing, Multicast routing and
       Trace and Monitoring support.  The object class is specified implicitly by the object  variable  name  in
       the description.  For example, $tcp implies the tcp object class and all of its child classes.

NODE OBJECTS

       [NOTE: This section has not been verified to be up-to-date with the release.]

       $node id
              Returns the node id.

       $node neighbors
              Returns a list of the neighbour node objects.

       $node attach agent
              Attach an agent of type agent to this node.

       $node detach agent
              Detach an agent of type agent from this node.

       $node agent port
              Return  a  handle to the agent attached to port port on this node.  Returns an empty string if the
              port is not in use.

       $node reset
              Reset all agents attached to this node.  This would re-initialize the state  variables  associated
              with the various agents at this node.

       $node rtObject?
              Returns  a  handle to rtObject if there exists an instance of the object at that node.  Only nodes
              that take part in a dynamic unicast routing protocol will have this object  (see  UNICAST  ROUTING
              METHODS and RTOBJECT OBJECTS section).

       $node join-group agent group
              Add  the  agent specified by the object handle agent to the multicast host group identified by the
              address group.  This causes the group membership protocol to arrange for the appropriate multicast
              traffic to reach this agent.  Multicast group address should be in the range 0x8000 - 0xFFFF.

       $node allocaddr
              Returns  multicast  group  address  in ascending order on each invocation starting from 0x8000 and
              ending at 0xFFFF.

       $node shape shape
              Set the shape of the node to "shape". When called before the simulator starts to run,  it  changes
              the default shape of the node in the nam trace file. The default shape of a node is """circle"""

       $node color color
              Set  the  color  of the node to color. It can be called anytime to change the current color of the
              node in nam trace file, if there is one.

       $node get-attribute name
              Get the specified attribute name of the node. Currently a Node object has  two  attributes:  COLOR
              and SHAPE. Note: these letters must be capital.

       $node add-mark name color shape
              Add  a  mark  (in  nam  trace  file)  with  color  and  shape  around  the  node. The shape can be
              """circle""", """hexagon""" and """square""" (case sensitive). The added mark will  be  identified
              by name.

       $node delete-mark name
              Delete the mark with name in the given node.

       There are no state variables or configuration parameters specific to the node class.

LINK OBJECTS

       [NOTE: This section has not been verified to be up-to-date with the release.]

       $link trace-dynamics ns fileID
              Trace  the  dynamics of this link and write the output to fileID filehandle.  ns is an instance of
              the Simulator or MultiSim object that  was  created  to  invoke  the  simulation  (see  TRACE  AND
              MONITORING METHODS section for the output trace format).

       $link trace-callback ns cmd
              Trace  all  packets  on  the  link  with  the  callback  cmd.  Cmd is invoked for each trace event
              (enqueue, dequeue, drop) with the text that would be logged as parameters.  (See  the  description
              of  the  log  file  for  this  information.)   A  demo  of  trace  callbacks  is  in  the  program
              tcl/ex/callback_demo.tcl in the distribution.

       $link color color
              Set the color of the Link object. It can be called anytime to change the current color of the link
              in nam trace file, if there is one.

       $link get-attribute name
              Get the specified attribute name of the Link. Currently a Link object has three attributes: COLOR,
              ORIENTATION, and QUEUE_POS.

       Currently the following two functions should not be directly  called.  Use  $ns  duplex-link-op  instead.
       Refer to the corresponding section in this man page.

       $link orient ori
              Set the orientation of the link to ori. When called before the simulator starts to run, it changes
              the default orientation of the link in nam  trace  file,  if  there  is  one.  If  orientation  is
              unspecified  for  any  link(s),  nam  will use automatic layout. The default orientation of a Link
              object is unspecified.

       $link queuePos pos
              Set the queue position of the link to pos. When called before the  simulator  starts  to  run,  it
              changes  the  default  queue placement of the simplex link in nam trace file, if there is one. pos
              specifies the angle between the horizontal line and the line along which queued  packets  will  be
              displayed.

SIMPLELINK OBJECTS

       [NOTE: This section has not been verified to be up-to-date with the release.]

       $link cost cost-val
              Make cost-val the cost of this link.

       $link cost?
              Return the cost of this link.

       Any configuration parameters or state variables?

DELAYLINK OBJECTS

       [NOTE:  This  section  has  not  been verified to be up-to-date with the release.]  The DelayLink Objects
       determine the amount of time required for a packet to traverse a link.  This is defined to be  size/bw  +
       delay  where  size  is the packet size, bw is the link bandwidth and delay is the link propagation delay.
       There are no methods or state variables associated with this object.

       Configuration Parameters

              bandwidth_
                     Link bandwidth in bits per second.

              delay_ Link propagation delay in seconds.

              There are no state variables associated with this object.

NETWORK DYNAMICS METHODS

       This section describes methods to make the links and nodes in the topology go up and  down  according  to
       various  distributions.   A dynamic routing protocol should generally be used whenever a simulation is to
       be done with network dynamics.  Note that a static topology model is the default in ns.

       $ns rtmodel model model-params node1 [node2]
              Make the link between node1 and node2 change between up and down states  according  to  the  model
              model.  In case only node1 is specified all the links incident on the node would be brought up and
              down according to the specified model.  model-params contains  the  parameters  required  for  the
              relevant  model  and  is to be specified as a list i.e. the parameters are to be enclosed in curly
              brackets.  model can be one of Deterministic, Exponential, Manual, Trace.  Returns a handle  to  a
              model object corresponding to the specified model.

              In  the  Deterministic model model-params is [start-time] up-interval down-interval [finish-time].
              Starting from start-time the link is made up for  up-interval  and  down  for  down-interval  till
              finish-time  is  reached.  The default values for start-time, up-interval, down-interval are 0.5s,
              2.0s, 1.0s respectively.  finish-time defaults to the  end  of  the  simulation.   The  start-time
              defaults to 0.5s in order to let the routing protocol computation quiesce.

              If  the  Exponential model is used model-params is of the form up-interval down-interval where the
              link up-time is an exponential distribution around the mean up-interval and the link down-time  is
              an  exponential  distribution  around  the mean down-interval.  Default values for up-interval and
              down-interval are 10s and 1s respectively.

              If the Manual distribution is used model-params is at op where at specifies the time at which  the
              operation  op  should  occur.   op is one of up, down.  The Manual distribution could be specified
              alternately using the rtmodel-at method described later in the section.

              If Trace is specified as the model the link/node dynamics is read from a  Tracefile.   The  model-
              params  argument  would  in  this  case  be the file-handle of the Tracefile that has the dynamics
              information.  The tracefile format is identical to  the  trace  output  generated  by  the  trace-
              dynamics link method (see TRACE AND MONITORING METHODS SECTION).

       $ns rtmodel-delete model-handle
              Delete the instance of the route model specified by model-handle.

       $ns rtmodel-at at op node1 [node2]
              Used to specify the up and down times of the link between nodes node1 and node2.  If only node1 is
              given all the links incident on node1 will be brought up and down.  at is the time  at  which  the
              operation op that can be either up or down is to be performed on the specified link(s).

QUEUE OBJECTS

       A queue object is a general class of object capable of holding and possibly marking or discarding packets
       as they travel through the simulated topology.

       Configuration Parameters

              limit_ The queue size in packets.

              blocked_
                     Set to false by default, this is true if the queue is blocked (unable to send a  packet  to
                     its downstream neighbor).

              unblock_on_resume_
                     Set to true by default, indicates a queue should unblock itself at the time the last packet
                     packet sent has been transmitted (but not necessarily received).

DROP-TAIL OBJECTS

       Drop-tail objects are a subclass of Queue objects that implement simple FIFO queue.  There are no methods
       that  are specific to drop-tail objects.  The only configuration parameter is drop-front_, which when set
       to true causes the queue to behave as a drop-from-front queueing discipline.  This  variable  is  set  to
       false by default.

FQ OBJECTS

       FQ  objects  are  a subclass of Queue objects that implement Fair queuing.  There are no methods that are
       specific to FQ objects.

       Configuration Parameters

              secsPerByte_

              There are no state variables associated with this object.

SFQ OBJECTS

       SFQ objects are a subclass of Queue objects that implement Stochastic Fair queuing.  There are no methods
       that are specific to SFQ objects.

       Configuration Parameters

              maxqueue_

              buckets_

              There are no state variables associated with this object.

DRR OBJECTS

       DRR  objects are a subclass of Queue objects that implement deficit round robin scheduling. These objects
       implement deficit round robin scheduling amongst different flows ( A particular flow  is  one  which  has
       packets  with  the same node and port id OR packets which have the same node id alone). Also unlike other
       multi-queue objects, this queue object implements a single shared buffer space for its different flows.

       Configuration Parameters

              buckets_
                     Indicates the total number of buckets to be used for hashing each of the flows.

              blimit_
                     Indicates the shared buffer size in bytes.

              quantum_
                     Indicates (in bytes) how much each flow can send during its turn.

              mask_  mask_, when set to 1, means that a particular flow consists of packets having the same node
                     id  (and possibly different port ids), otherwise a flow consists of packets having the same
                     node and port ids.

RED OBJECTS

       RED objects are a subclass of Queue objects that implement random early-detection gateways.   The  object
       can  be  configured  to  either  drop or ``mark'' packets.  There are no methods that are specific to RED
       objects.

       Configuration Parameters

              bytes_ Set to "true" to enable ``byte-mode'' RED, where the size of arriving  packets  affect  the
                     likelihood of marking (dropping) packets.

              queue-in-bytes_
                     Set  to  "true"  to  measure the average queue size in bytes rather than packets.  Enabling
                     this option also causes thresh_ and maxthresh_ to be automatically scaled by  mean_pktsize_
                     (see below).

              thresh_
                     The minimum threshold for the average queue size in packets.

              maxthresh_
                     The maximum threshold for the average queue size in packets.

              mean_pktsize_
                     A  rough  estimate  of  the  average packet size in bytes.  Used in updating the calculated
                     average queue size after an idle period.

              q_weight_
                     The queue weight, used in the  exponential-weighted  moving  average  for  calculating  the
                     average queue size.

              wait_  Set to true to maintain an interval between dropped packets.

              linterm_
                     As  the  average  queue size varies between "thresh_" and "maxthresh_", the packet dropping
                     probability varies between 0 and "1/linterm".

              setbit_
                     Set to "true" to mark packets by setting the congestion indication bit  in  packet  headers
                     rather than drop packets.

              drop-tail_
                     Set  to  true  to  use  drop-tail rather than random-drop or drop-from-front when the queue
                     overflows or the average queue size exceeds "maxthresh_".  This is  the  default  behavior.
                     For a further explanation of these variables, see [2].

              drop-rand_
                     Set  to  true  to  use  random-drop rather than drop-tail or drop-from-front when the queue
                     overflows or the average queue size exceeds "maxthresh_".

              drop-front_
                     Set to true to use drop-from-front rather than drop-tail or  random  drop  when  the  queue
                     overflows or the average queue size exceeds "maxthresh_".

              ns1-compat_
                     Set  to true to avoid resetting the count since the last packet drop, after a forced packet
                     is dropped.  This gives compatibility with previous behavior of RED.  The default is set to
                     false.

              entle_ Set  to  true  to increase the packet drop rate slowly from max_p to 1 as the average queue
                     size ranges from maxthresh to twice maxthresh.  The default is  set  to  false,  and  max_p
                     increases abruptly from max_p to 1 when the average queue size exceeds maxthresh.

              State Variables
                     None of the state variables of the RED implementation are accessible.

CBQ OBJECTS

       CBQ objects are a subclass of Queue objects that implement class-based queueing.

       $cbq insert $class
              Insert traffic class class into the link-sharing structure associated with link object cbq.

       $cbq bind $cbqclass $id1 [$id2]
              Cause  packets  containing  flow  id  $id1  (or  those  in the range $id1 to $id2 inclusive) to be
              associated with the traffic class $cbqclass.

       $cbq algorithm $alg
              Select the CBQ internal algorithm.  $alg may be set to one of:  "ancestor-only",  "top-level",  or
              "formal".

CBQ/WRR OBJECTS

       CBQ/WRR  objects  are  a  subclass  of  CBQ  objects that implement weighted round-robin scheduling among
       classes of the same priority level.  In contrast,  CBQ  objects  implement  packet-by-packet  round-robin
       scheduling among classes of the same priority level.

       Configuration Parameters

              maxpkt_
                     The  maximum  size of a packet in bytes.  This is used only by CBQ/WRR objects in computing
                     maximum bandwidth allocations for the weighted round-robin scheduler.

CBQCLASS OBJECTS

       CBQClass objects implement the traffic classes associated with CBQ objects.

       $cbqclass setparams parent okborrow allot maxidle prio level extradelay
              Sets several of the configuration parameters for the CBQ traffic class (see below).

       $cbqclass parent [$cbqcl|none]
              specify the parent of this class in the  link-sharing  tree.   The  parent  may  be  specified  as
              ``none'' to indicate this class is a root.

       $cbqclass newallot $a
              Change the link allocation of this class to the specified amount (in range 0.0 to 1.0).  Note that
              only the specified class is affected.

       $cbqclass install-queue $q
              Install a Queue object into the compound CBQ or CBQ/WRR link structure.   When  a  CBQ  object  is
              initially created, it includes no internal queue (only a packet classifier and scheduler).

       Configuration Parameters

              okborrow_
                     is a boolean indicating the class is permitted to borrow bandwidth from its parent.

              allot_ is the maximum fraction of link bandwidth allocated to the class expressed as a real number
                     between 0.0 and 1.0.

              maxidle_
                     is the maximum amount of time a class may be required to have  its  packets  queued  before
                     they are permitted to be forwarded

              priority_
                     is the class' priority level with respect to other classes.  This value may range from 0 to
                     10, and more than one class may exist at the same priority.   Priority  0  is  the  highest
                     priority.

              level_ is the level of this class in the link-sharing tree.  Leaf nodes in the tree are considered
                     to be at level 1; their parents are at level 2, etc.

              extradelay_
                     increase the delay experienced by a delayed class by the specified number of seconds.

QUEUEMONITOR Objects

       QueueMonitor Objects are used to monitor a set of packet and byte arrival, departure and  drop  counters.
       It  also  includes  support  for  aggregate  statistics  such as average queue size, etc.  [see TRACE AND
       MONITORING METHODS].

       $queuemonitor reset
              reset all the cumulative counters described below  (arrivals,  departures,  and  drops)  to  zero.
              Also, reset the integrators and delay sampler, if defined.

       $queuemonitor set-delay-samples delaySamp_
              Set  up  the  Samples  object delaySamp_ to record statistics about queue delays.  delaySamp_ is a
              handle to a Samples object i.e the Samples object should have already been created.

       $queuemonitor get-bytes-integrator
              Returns an Integrator object that can be used to find the integral of the  queue  size  in  bytes.
              (see Integrator Objects section).

       $queuemonitor get-pkts-integrator
              Returns  an  Integrator object that can be used to find the integral of the queue size in packets.
              (see Integrator Objects section).

       $queuemonitor get-delay-samples
              Returns a Samples object delaySamp_ to record statistics about queue delays (see  Samples  Objects
              section).

       There are no configuration parameters specific to this object.

       State Variables

              size_  Instantaneous queue size in bytes.

              pkts_  Instantaneous queue size in packets.

              parrivals_
                     Running total of packets that have arrived.

              barrivals_
                     Running total of bytes contained in packets that have arrived.

              pdepartures_
                     Running total of packets that have departed (not dropped).

              bdepartures_
                     Running total of bytes contained in packets that have departed (not dropped).

              pdrops_
                     Total number of packets dropped.

              bdrops_
                     Total number of bytes dropped.

              bytesInt_
                     Integrator object that computes the integral of the queue size in bytes.  The sum_ variable
                     of this object has the running sum (integral) of the queue size in bytes.

              pktsInt_
                     Integrator object that computes the integral of  the  queue  size  in  packets.   The  sum_
                     variable of this object has the running sum (integral) of the queue size in packets.

QUEUEMONITOR/ED Objects

       This  derived  object  is  capable of differentiating regular packet drops from early drops.  Some queues
       distinguish regular drops (e.g. drops due to buffer exhaustion) from other drops (e.g.  random  drops  in
       RED queues).  Under some circumstances, it is useful to distinguish these two types of drops.

       State Variables

              epdrops_
                     The number of packets that have been dropped ``early''.

              ebdrops_
                     The number of bytes comprising packets that have been dropped ``early''

       Note:  because  this  class  is a subclass of QueueMonitor, objects of this type also have fields such as
       pdrops_ and bdrops_.  These fields describe the total number of dropped packets and bytes, including both
       early and non-early drops.

QUEUEMONITOR/ED/FLOWMON Objects

       These objects may be used in the place of a conventional QueueMonitor object when wishing to collect per-
       flow counts and statistics in addition to the aggregate counts  and  statistics  provided  by  the  basic
       QueueMonitor.

       $fmon classifier [$cl]
              insert  (read)  the specified classifier into (from) the flow monitor object.  This is used to map
              incoming packets to which flows they are associated with.

       $fmon dump
              Dump the current per-flow counters and statistics to the  I/O  channel  specified  in  a  previous
              attach operation.

       $fmon flows
              Return  a  character  string  containing the names of all flow objects known by this flow monitor.
              Each of these objects are of type QueueMonitor/ED/Flow.

       $fmon attach $chan
              Attach a tcl I/O channel to the flow monitor.  Flow statistics are written to the channel when the
              dump operation is executed.

       Configuration Parameters

              enable_in_
                     Set  to  true  by default, indicates that per-flow arrival state should be kept by the flow
                     monitor.  If set to false, only the aggregate arrival information is kept.

              enable_out_
                     Set to true by default, indicates that per-flow departure state should be kept by the  flow
                     monitor.  If set to false, only the aggregate departure information is kept.

              enable_drop_
                     Set  to  true  by  default,  indicates  that per-flow drop state should be kept by the flow
                     monitor.  If set to false, only the aggregate drop information is kept.

              enable_edrop_
                     Set to true by default, indicates that per-flow early drop state should be kept by the flow
                     monitor.  If set to false, only the aggregate early drop information is kept.

QUEUEMONITOR/ED/FLOW Objects

       These  objects  contain per-flow counts and statistics managed by a QUEUEMONITOR/ED/FLOWMON object.  They
       are generally created in an OTcl callback procedure when a flow monitor is given a packet it  cannot  map
       on  to a known flow.  Note that the flow monitor's classifier is responsible for mapping packets to flows
       in some arbitrary way.  Thus, depending on the type of classifier used, not all of  the  state  variables
       may  be  relevant  (e.g.  one  may  classify  packets based only on flow id, in which case the source and
       destination addresses may not be significant).

       State Variables

              src_   The source address of packets belonging to this flow.

              dst_   The destination address of packets belonging to this flow.

              flowid_
                     The flow id of packets belonging to this flow.

UNICAST ROUTING METHODS

       A dynamic unicast routing protocol can be specified to run on a subset of nodes in  the  topology.   Note
       that  a  dynamic  routing  protocol  should  be generally used whenever a simulation is done with network
       dynamics.

       $ns rtproto proto node-list
              Specifies the dynamic unicast routing protocol proto to be run on the  nodes  specified  by  node-
              list.  Currently proto can be one of Static, Session, DV.  Static routing is the default.  Session
              implies that the unicast routes over the entire topology are instantaneously recomputed whenever a
              link  goes  up  or  down.   DV  implies  that  a  simple distance vector routing protocol is to be
              simulated.  node-list defaults to all the nodes in the topology.

       $ns compute-routes
              Compute routes between all the nodes in the topology.  This can be used if static routing is  done
              and  the  routes  have  to  be  recomputed  as the state of a link has changed.  Note that Session
              routing (see rtproto method above) will recompute routes automatically whenever the state  of  any
              link in the topology changes.

       $ns get-routelogic
              Returns an handle to a RouteLogic object that has methods for route table lookup etc.

ROUTELOGIC OBJECTS

       $routelogic lookup srcid destid
              Returns  the  id  of the node that is the next hop from the node with id srcid to the node with id
              destid.

       $routelogic dump nodeid
              Dump the routing tables of all nodes whose id  is  less  than  nodeid.   Node  ids  are  typically
              assigned to nodes in ascending fashion starting from 0 by their order of creation.

RTOBJECT OBJECTS

       Every  node  that takes part in a dynamic unicast routing protocol will have an instance of rtObject (see
       NODE OBJECTS section for the method to get an handle to this object at a  particular  node).   Note  that
       nodes  will not have an instance of this object if Session routing is done as a detailed routing protocol
       is not being simulated in this case.

       $rtobject dump-routes fileID
              Dump the routing table to the output channel specified by fileID.  fileID must be  a  file  handle
              returned by the Tcl open command and it must have been opened for writing.

       $rtobject rtProto? proto
              Returns  a  handle  to  the  routing  protocol agent specified by proto if it exists at that node.
              Returns an empty string otherwise.

       $rtobject nextHop? destID
              Returns the id of the node that is the next hop to the  destination  specified  by  the  node  id,
              destID.

       $rtobject rtpref? destID

       $rtobject metric? destID

MULTICAST ROUTING METHODS

       Multicast  routing  is  enabled  by  setting Simulator EnableMcast_ variable to 1 at the beginning of the
       simulation.  Note that this variable must be set before any node, link or agent objects  are  created  in
       the  simulation.   Also  links must have been created with interface labels (see simplex-link and duplex-
       link methods in NS COMMANDS section).

       $ns mrtproto proto node-list
              Specifies the multicast routing protocol proto to be run on  the  nodes  specified  by  node-list.
              Currently  proto  can be one of CtrMcast, DM, detailedDM, dynamicDM, pimDM.  node-list defaults to
              all the nodes in the topology.  Returns an handle to a protocol-specific object that has  methods,
              configuration  parameters  specific  to that protocol.  Note that currently CtrMcastComp object is
              returned if CtrMcast is used but a null string is returned if DM, detailedDM, dynamicDM  or  pimDM
              are used.

              If  proto is 'CtrMcast' a Rendezvous Point (RP) rooted shared tree is built for a multicast group.
              The actual sending of prune, join messages etc.  to set up state at the nodes is not simulated.  A
              centralized  computation  agent  is  used  to  compute  the  fowarding  trees and set up multicast
              forwarding state, (*,G) at the relevant nodes as new receivers join a group.   Data  packets  from
              the  senders  to  a  group are unicast to the RP.  Methods are provided in the CtrMcastComp object
              (see CTRMCASTCOMP OBJECTS section) that is returned  by  mrtproto  to  switch  to  source-specific
              trees,  choose some nodes as candidate RPs etc.  When a node/link on a multicast distribution tree
              goes down, the tree is instanteously recomputed.

              If proto is 'DM' DVMRP-like dense mode is simulated.  Parent-child lists are used  to  reduce  the
              number  of  links  over which the data packets are broadcast.  Prune messages are sent by nodes to
              remove branches from the multicast forwarding tree that do not lead to  any  group  members.   The
              prune  timeout value is 0.5s by default (see DM OBJECTS section to change the default).  This does
              not adapt to network changes.  There is also  currently  no  support  for  proper  functioning  in
              topologies with LANs.

              If  proto  is  'detailedDM'  a dense mode protocol based on Protocol Independent Multicast - Dense
              Mode (PIM-DM) is simulated.  This is currently  the  most  complete  version  of  the  dense  mode
              protocol  in  the  simulator  and  is recommended for use over the other dense mode protocols.  It
              adapts to network dynamics and functions correctly in topologies with LANs (where LANs are created
              using  the  multi-link-of-interfaces  method  -  see  NS  COMMANDS).   In  case there are multiple
              potential forwarders for a LAN, the node with the highest id is chosen as the forwarder  (this  is
              done  through the Assert mechanism).  The default values for the prune timeout, interface deletion
              timeout (used for LANs) and graft retransmission timeout are 0.5s, 0.1s  and  0.05s  respectively.
              (see Prune/Iface/Timer, Deletion/Iface/Timer and GraftRtx/Timer objects respectively to change the
              default values and for more information about the timers).

              If proto is 'dynamicDM'  DVMRP-like  dense  mode  protocol  that  adapts  to  network  changes  is
              simulated.  'Poison-reverse' information (i.e. the information that a particular neighbouring node
              uses this node to reach a particular network) is read from  the  routing  tables  of  neighbouring
              nodes  in  order  to  adapt  to network dynamics (DVMRP runs its own unicast routing protocol that
              exchanges this information).  The current implementation does not support  proper  functioning  in
              topologies  with  LANs.   The  prune  timeout  value is 0.5s by default (see DM OBJECTS section to
              change the default).

              If proto is 'pimDM' Protocol Independent Multicast - Dense mode is simulated.  In  this  case  the
              data  packets  are broadcast over all the outgoing links except the incoming link.  Prune messages
              are sent by nodes to remove the branches of the multicast forwarding tree that do not lead to  any
              group members.  The current implementation does not adapt to network dynamics and does not support
              proper functioning in topologies with LANs.  The prune timeout value is 0.5s by  default  (see  DM
              OBJECTS section to change the default).

CTRMCASTCOMP OBJECTS

       A handle to the CtrMcastComp object is returned when the protocol is specified as 'CtrMcast' in mrtproto.

       $ctrmcastcomp switch-treetype group-addr
              Switch  from  the  Rendezvous  Point  rooted  shared  tree  to source-specific trees for the group
              specified by group-addr.  Note that this method cannot be  used  to  switch  from  source-specific
              trees back to a shared tree for a multicast group.

       $ctrmcastcomp set_c_rp node-list
              Make  all  the nodes specified in node-list as candidate RPs and change the state of all the other
              nodes to not be candidate RPs.  Note that all nodes are candidate RPs by default.   Currently  the
              node  with  the  highest node id serves as the RP for all multicast groups.  This method should be
              invoked before any source starts sending packets to the group or any receiver joins the group.

       $ctrmcastcomp get_rp node group
              Returns the RP for the group as seen by the node node for the multicast group with address  group-
              addr.  Note that different nodes may see different RPs for the group if the network is partitioned
              as the nodes might be in different partitions.

DM OBJECTS

       DM Objects implement DVMRP style densemode multicast where parent-child lists  are  used  to  reduce  the
       number  of  links over which initial data packets are broadcast.  There are no methods or state variables
       specific to this object.

       Configuration parameters

              PruneTimeout

              Timeout value for the prune state at nodes.

PRUNE/IFACE/TIMER OBJECTS

       The Prune/Iface/Timer objects are used to implement the prune timer for detailedDM.  There are no methods
       or state variables specific to this object.

       Configuration parameters

              timeout

              Timeout value for the prune state at nodes.

DELETION/IFACE/TIMER OBJECTS

       The Deletion/Iface/Timer objects are used to implement the interface deletion timer that are required for
       correct functioning at nodes that are part of LANs.  If a node has a LAN as its  incoming  interface  for
       packets  from  a  certain source and it does not have any downstream members it sends out a prune message
       onto the LAN.  Any node that has the LAN as its incoming interface for the same source and has downstream
       members  on  hearing the prune message sent on the LAN.  will send a join message onto the LAN.  When the
       node that is acting as the forwarder for the LAN hears the prune  message  from  the  LAN,  it  does  not
       immediately  prune  off the LAN as its outgoing interface.  Instead it starts an interface deletion timer
       for the outgoing interface.  The forwarder will remove the LAN as its outgoing interface only if it  does
       not  receive  any  join messages from the LAN before its deletion timer expires.  There are no methods or
       state variables specific to this object.

       Configuration parameters

              timeout

              Timeout value for the interface deletion timer.

GRAFTRTX/TIMER OBJECTS

       The GraftRtx/Timer objects are used to implement the graft retransmission timer at  nodes.   This  is  to
       ensure the reliability of grafts sent upstream by a node.

       Configuration parameters

              timeout

              Timeout value for the graft retransmission timer.

AGENT OBJECTS

       [NOTE: This section has not been verified to be up-to-date with the release.]

       $agent port
              Return the transport-level port of the agent.  Ports are used to identify agents within a node.

       $agent dst-addr
              Return the address of the destination node this agent is connected to.

       $agent dst-port
              Return the port at the destination node that this agent is connected to.

       $agent attach-source type
              Install  a  data  source  of type type in this agent.  type is one of FTP or bursty[???].  See the
              corresponding object methods for information on configuration parameters.  Returns a handle to the
              source object.

       $agent attach-traffic traffic-object
              Attach traffic-object to this agent traffic-object is an instance of Traffic/Expoo, Traffic/Pareto
              or Traffic/Trace.  Traffic/Expoo generates traffic based on an  Exponential  On/Off  distribution.
              Traffic/Pareto  generates  traffic based on a Pareto On/Off distribution.  Traffic/Trace generates
              traffic from a trace file.  The relevant configuration parameters for each of  the  above  objects
              can be found in the TRAFFIC METHODS section.

       $agent connect addr port
              Connect this agent to the agent identified by the address addr and port port.  This causes packets
              transmitted from this agent to contain the address and port indicated, so that  such  packets  are
              routed to the intended agent.  The two agents must be compatible (e.g., a tcp-source/tcp-sink pair
              as opposed a cbr/tcp-sink pair).  Otherwise, the results of the simulation are unpredictable.

       Configuration Parameters

              dst_   Address of destination that the agent is connected to. Currently 32 bits with the higher 24
                     bits the destination node ID and the lower 8 bits being the port number.

              There are no state variables specific to the generic agent class.

NULL OBJECTS

       [NOTE:  This  section  has  not  been  verified  to  be up-to-date with the release.]  Null objects are a
       subclass of agent objects that implement a traffic sink.  They inherit all of the  generic  agent  object
       functionality.   There  are  no  methods,  configuration  parameters  or state variables specific to this
       object.

LOSSMONITOR OBJECTS

       [NOTE: This section has not been verified to be up-to-date with the release.]  LossMonitor objects are  a
       subclass  of  agent  objects that implement a traffic sink which also maintains some statistics about the
       received data e.g., number of bytes received, number of packets  lost  etc.   They  inherit  all  of  the
       generic agent object functionality.

       $lossmonitor clear
              Resets the expected sequence number to -1.

       Configuration Parameters

              There are no configuration parameters specific to this object.

       State Variables

              nlost_ Number of packets lost.

              npkts_ Number of packets received.

              bytes_ Number of bytes received.

              lastPktTime_
                     Time at which the last packet was received.

              expected_
                     The expected sequence number of the next packet.

TCP OBJECTS

       TCP  objects  are  a  subclass  of  agent  objects that implement the BSD Tahoe TCP transport protocol as
       described in [7].  They inherit all of the generic agent functionality.

       To trace TCP parameters, mark each parameter with ``$tcp trace window_'' and then send the  output  to  a
       trace file with ``$tcp attach [open trace.tr w]''.

       Tcp  segments  can  be  sent  with  the advance and advanaceby commands.  When all data is sent, the done
       method will be invoked (which can be overridden in OTcl).

       $tcp advance n
              Send up to the nth packets.

       $tcp advanceby n
              Send n more packets.

       $tcp done
              Functional called when all packets (specified by advance/advanceby/maxpkts_) have been sent.   Can
              be overriden on a per-object basis.

              Configuration Parameters

              window_
                     The upper bound on the advertised window for the TCP connection (in packets).

              maxcwnd_
                     The  upper  bound  on the congestion window for the TCP connection.  Set to zero to ignore.
                     (This is the default.)  Measured in packets.

              windowInit_
                     The initial size of the congestion window on slow-start.  (in packets).

              wnd_init_option_
                     The algorithm used for determining the initial size of the congestion window.  Set to 1 for
                     a  static algorithm using the value in windowInit_.  Set to 2 for a dynamic algorithm using
                     a function of packetSize_.

              syn_   Set to true to model the initial SYN/ACK exchange in one-way TCP.  Set to false as default.

              delay_growth_
                     Set to true to delay the initial congestion window until after one packet has been sent and
                     acked.  Set to false as default.

              windowOption_
                     The  algorithm  to  use  for  managing the congestion window in linear phase.  The standard
                     algorithm is 1 (the default).  Other experimental algorithms are documented in  the  source
                     code.

              windowThresh_
                     Gain  constant  to  exponential  averaging  filter  used  to compute awnd (see below).  For
                     investigations of different window-increase algorithms.

              overhead_
                     The range (in seconds) of a uniform random variable used to delay each output packet.   The
                     idea is to insert random delays at the source in order to avoid phase effects, when desired
                     [4].  This has only been implemented for the Tahoe ("tcp") version of  tcp,  not  for  tcp-
                     reno.  This is not intended to be a realistic model of CPU processing overhead.

              ecn_   Set  to  true to use explicit congestion notification in addition to packet drops to signal
                     congestion.  This allows a Fast Retransmit  after  a  quench()  due  to  an  ECN  (explicit
                     congestion notification) bit.

              packetSize_
                     The size in bytes to use for all packets from this source.

              tcpip_base_hdr_size_
                     The size in bytes of the base TCP/IP header.

              tcpTick_
                     The TCP clock granularity for measuring roundtrip times.  Note that it is set by default to
                     the non-standard value of 100ms.  Measured in seconds.

              bugFix_
                     Set to true to remove a bug when multiple fast retransmits are allowed for packets  dropped
                     in a single window of data.

              maxburst_
                     Set  to  zero to ignore.  Otherwise, the maximum number of packets that the source can send
                     in response to a single incoming ACK.

              slow_start_restart_
                     Boolean; set to 1 to slow-start after the connection goes idle.  On by default.

              srtt_init_
                     Initial value for the smoothed roundtrip time estimate.  Default is 0 seconds.

              t_rttvar_
                     Initial value for the variance in roundtrip time.  Default is 3 seconds.

              rtxcur_init_
                     Initial value for the retransmit value.  Default is 6 seconds.

              T_SRTT_BITS
                     Exponent of weight for updating the smoothed round-trip time t_srtt_.  Default is 3, for  a
                     weight of 1/2^T_SRTT_BITS or 1/8.

              T_RTTVAR_BITS
                     Exponent  of weight for updating variance in round-trip time, t_rttvar_.  Default is 2, for
                     a weight of 1/2^T_RTTVAR_BITS or 1/4.

              rttvar_exp_
                     Exponent of multiple of the mean deviation in  calculating  the  current  retransmit  value
                     t_rtxcur_.  Default is 2, for a multiple of 2^rttvar_exp_ or 4.

       Defined Constants

              MWS    The  Maximum  Window  Size  in packets for a TCP connection.  MWS determines the size of an
                     array in tcp-sink.cc.  The default for MWS is 1024 packets.  For Tahoe  TCP,  the  "window"
                     parameter,  representing  the receiver's advertised window, should be less than MWS-1.  For
                     Reno TCP, the "window" parameter should be less than (MWS-1)/2.

       State Variables

              dupacks_
                     Number of duplicate acks seen since any new data was acknowledged.

              seqno_ Highest sequence number for data from data source to TCP.

              t_seqno_
                     Current transmit sequence number.

              ack_   Highest acknowledgment seen from receiver.

              cwnd_  Current value of the congestion window (in packets).

              awnd_  Current value of a low-pass filtered version of the congestion window.  For  investigations
                     of different window-increase algorithms.

              ssthresh_
                     Current value of the slow-start threshold (in packets).

              rtt_   Round-trip time estimate.  In seconds (expressed in multiples of tcpTick_).

              srtt_  Smoothed round-trip time estimate.  In seconds (in multiples of tcpTick_/8).

              rttvar_
                     Round-trip time mean deviation estimate.

              t_rtxcur_
                     Current retransmit value.  In seconds.

              backoff_
                     Round-trip time exponential backoff constant.

TCP/RENO OBJECTS

       TCP/Reno  objects  are  a  subclass  of  TCP  objects  that  implement the Reno TCP transport protocol as
       described in [7].  There are no methods, configuration parameters or state  variables  specific  to  this
       object.

TCP/NEWRENO OBJECTS

       TCP/Newreno  objects  are a subclass of TCP objects that implement a modified version of the BSD Reno TCP
       transport protocol.

       There are no methods or state variables specific to this object.

       Configuration Parameters

              newreno_changes_
                     Set to zero for the default NewReno described in [7].  Set  to  1  for  additional  NewReno
                     algorithms  as  suggested  in  [10]; this includes the estimation of the ssthresh parameter
                     during slow-start.

TCP/VEGAS OBJECTS

       This section of the man page has not yet been written.

TCP/SACK1 OBJECTS

       TCP/Sack1 objects are a subclass of TCP objects that implement the BSD Reno TCP transport  protocol  with
       Selective Acknowledgement Extensions as described in [7].

       They  inherit  all  of  the  TCP object functionality.  There are no methods, configuration parameters or
       state variables specific to this object.

TCP/FACK OBJECTS

       TCP/Fack objects are a subclass of TCP objects that implement the BSD Reno TCP  transport  protocol  with
       Forward Acknowledgement congestion control.

       They  inherit  all  of the TCP object functionality.  There are no methods or state variables specific to
       this object.

       Configuration Parameters

              ss-div4
                     Overdamping algorithm. Divides ssthresh by 4 (instead  of  2)  if  congestion  is  detected
                     within 1/2 RTT of slow-start. (1=Enable, 0=Disable)

              rampdown
                     Rampdown  data  smoothing algorithm. Slowly reduces congestion window rather than instantly
                     halving it. (1=Enable, 0=Disable)

TCP/FULLTCP OBJECTS

       This section has not yet been added to the man page.  The implementation and the configuration parameters
       are described in [11].

TCPSINK OBJECTS

       TCPSink objects are a subclass of agent objects that implement a receiver for TCP packets.  The simulator
       only implements "one-way" TCP connections, where the TCP source sends data packets and the TCP sink sends
       ACK  packets.   TCPSink  objects inherit all of the generic agent functionality.  There are no methods or
       state variables specific to the TCPSink object.

       Configuration Parameters

              packetSize_
                     The size in bytes to use for all acknowledgment packets.

              maxSackBlocks_
                     The maximum number of blocks of data that can be acknowledged in  a  SACK  option.   For  a
                     receiver  that is also using the time stamp option [RFC 1323], the SACK option specified in
                     RFC 2018 has room to include three SACK blocks.  This is only  used  by  the  TCPSink/Sack1
                     subclass.   This value may not be increased within any particular TCPSink object after that
                     object has been allocated.  (Once a TCPSink object has been allocated, the  value  of  this
                     parameter may be decreased but not increased).

TCPSINK/DELACK OBJECTS

       DelAck  objects  are  a  subclass of TCPSink that implement a delayed-ACK receiver for TCP packets.  They
       inherit all of the TCPSink object functionality.  There are no methods or state variables specific to the
       DelAck object.

       Configuration Parameters

              interval_
                     The  amount  of  time to delay before generating an acknowledgment for a single packet.  If
                     another packet arrives before this time expires, generate an acknowledgment immediately.

TCPSINK/SACK1 OBJECTS

       TCPSink/Sack1 objects are a subclass of TCPSink that implement a SACK receiver  for  TCP  packets.   They
       inherit all of the TCPSink object functionality.  There are no methods, configuration parameters or state
       variables specific to this object.

TCPSINK/SACK1/DELACK OBJECTS

       TCPSink/Sack1/DelAck objects are a subclass of TCPSink/Sack1 that implement a delayed-SACK  receiver  for
       TCP  packets.  They inherit all of the TCPSink/Sack1 object functionality.  There are no methods or state
       variables specific to this object.

       Configuration Parameters

              interval_
                     The amount of time to delay before generating an acknowledgment for a  single  packet.   If
                     another packet arrives before this time expires, generate an acknowledgment immediately.

SRM OBJECTS

       SRM objects are a subclass of agent objects that implement the SRM reliable multicast transport protocol.
       They inherit all of the generic agent functionalities.

       $srm traffic-source source
              Attach a traffic source, e.g., Application/Traffic/CBR, to the SRM agent.

       $srm start
              Join the multicast group, start the SRM agent and its attached traffic source.

       $srm delete
              Stop the SRM agent, delete all its status and detach the traffic source.

       $srm trace trace-file
              Write the traces generated by the SRM agent to trace-file. The  traces  includes  timer  settings,
              request  and  repair  sending  and receipts, etc. Two related files that are not built into ns are
              tcl/mcast/srm-debug.tcl that permits more detailed tracing of the delay computation functions, and
              tcl/mcast/srm-nam.tcl  that separately marks srm control messages from data.  The latter is useful
              to enhance nam visualisation.

       $srm log log-file
              Write the recovery statistics during each request or repair to log-file.  The  statistics  include
              start time, duration, message id, total number of duplicate requests and repairs.

       $srm distance? node
              Return the distance estimate to node in this SRM agent.

       $srm distances? node
              Returns a list of <group member,  distance> tuples of the distances to all group members that this
              node is aware of.  The group member is identified as the address of the remote agent.   The  first
              tuple is this agent's token.  The list can be directly loaded into a Tcl array.

       Configuration Parameters

              packetSize_
                     The  data  packet size in bytes that will be used for repair messages. The default value is
                     1024.

              requestFunction_
                     The algorithm used to produce a retransmission request, e.g., setting request  timers.  The
                     default  value  is  SRM/request. Other possible request functions are SRM/request/Adaptive,
                     used by the Adaptive SRM code.

              repairFunction_
                     The algorithm used to produce a repair, e.g., compute repair timers. The default  value  is
                     SRM/repair.  Other possible request functions are SRM/repair/Adaptive, used by the Adaptive
                     SRM code.

              sessionFunction_
                     The algorithm used to generate session messages. Default is SRM/session

              sessionDelay_
                     The basic interval of session messages. Slight random variation is added to  this  interval
                     to  avoid global synchronization of session messages. User may want to adjust this variable
                     according to their specific simulation.  Measured in seconds; default value is 1.0 seconds.

              C1_, C2_
                     The parameters which control the request timer. Refer to [8] for detail. The default  value
                     is C1_ = C2_ = 2.0.

              D1_, D2_
                     The  parameters  which control the repair timer. Refer to [8] for detail. The default value
                     is D1_ = D2_ = 1.0.

              requestBackoffLimit_
                     The maximum number of exponential backoffs. Default value is 5.

       State Variables

              stats_ An array containing multiple statistics needed by adaptive SRM agent.  Including: duplicate
                     requests and repairs in current request/repair period, average number of duplicate requests
                     and repairs, request and repair delay in current request/repair period, average request and
                     repair delay.

SRM/Adaptive OBJECTS

       SRM/Adaptive objects are a subclass of the SRM objects that implement the adaptive SRM reliable multicast
       transport protocol. They inherit all of the SRM object functionalities.

       State Variables Refer to the SRM paper by Sally et al ([11]) for more detail.

              pdistance_
                     This variable is used to pass the distance estimate provided  by  the  remote  agent  in  a
                     request or repair message.

              D1_, D2_
                     The  same as that in SRM agents, except that they are initialized to log10(group size) when
                     generating the first repair.

              MinC1_, MaxC1_, MinC2_, MaxC2_
                     The minimum/maximum values of C1_ and C2_. Default  initial  values  are  defined  in  [8].
                     These values define the dynamic range of C1_ and C2_.

              MinD1_, MaxD1_, MinD2_, MaxD2_
                     The minimum/maximum values of D1_ and D2_. Default initial values are defined in [8]. These
                     values define the dynamic range of D1_ and D2_.

              AveDups
                     Higher bound for average duplicates.

              AveDelay
                     Higher bound for average delay.

              eps    AveDups - dups determines the lower bound of the  number  of  duplicates,  when  we  should
                     adjust parameters to decrease delay.

APPLICATION OBJECTS

       Application objects generate data for transport agents to send.

FTP APPLICATION OBJECTS

       Application/FTP objects  produce bulk data for a TCP object to send.

       $ftp start
              Causes FTP to produce packets indefinitely.

       $ftp produce n
              Causes the FTP object to produce n packets instantaneously.

       $ftp stop
              Causes the attached TCP object to stop sending data.

       $ftp attach agent
              Attaches an Application/FTP object to agent.

       $ftp producemore count
              Causes the Application/FTP object to produce count more packets.

       Configuration Parameters

              maxpkts
                     The maximum number of packets generated.

TELNET APPLICATION OBJECTS

       Application/Telnet  objects produce individual packets with inter-arrival times as follows.  If interval_
       is non-zero, then inter-arrival times are chosen from an exponential distribution with average interval_.
       If interval_ is zero, then inter-arrival times are chosen using the "tcplib" telnet distribution.

       $telnet start
              Causes the Application/Telnet object to start producing packets.

       $telnet stop
              Causes the Application/Telnet object to stop producing packets.

       $telnet attach agent
              Attaches a Application/Telnet object to agent.

       Configuration Parameters

              interval_
                     The  average  inter-arrival time in seconds for packets generated by the Application/Telnet
                     object.

TRAFFIC OBJECTS

       Traffic objects create data  for  a  transport  protocol  to  send.   A  Traffic  object  is  created  by
       instantiating  an object of class Application/Traffic/type where type is one of Exponential, Pareto, CBR,
       Trace.

EXPONENTIAL TRAFFIC OBJECTS

       Application/Traffic/Exponential objects generate  On/Off  traffic.   During  "on"  periods,  packets  are
       generated at a constant burst rate.  During "off" periods, no traffic is generated.  Burst times and idle
       times are taken from exponential distributions.

       Configuration Parameters

              packet_size_
                     The packet size in bytes.

              burst_time_
                     Burst duration in seconds.

              idle_time_
                     Idle time in seconds.

              rate_  Peak rate in bits per second.

PARETO TRAFFIC OBJECTS

       Application/Traffic/Pareto objects generate On/Off traffic with burst times and  idle  times  taken  from
       pareto distributions.

       Configuration Parameters

              packet_size_
                     The packet size in bytes.

              burst_time_
                     Average on time in seconds.

              idle_time_
                     Average off time in seconds.

              rate_  Peak rate in bits per second.

              shape_ Pareto shape parameter.

CBR (CONSTANT BIT RATE) TRAFFIC OBJECTS

       Application/Traffic/CBR  objects  generate  packets  at  a  constant  rate.   Dither  can be added to the
       interarrival times by enabling the "random" flag.

       Configuration Parameters

              rate_  Peak rate in bits per second.

              packet_size_
                     The packet size in bytes.

              random_
                     Flag that turns dithering on and off (default is off).

              maxpkts_
                     Maximum number of packets to send.

TRACE TRAFFIC OBJECTS

       Application/Traffic/Trace objects are used to generate traffic from a trace file.

       $trace attach-tracefile tfile
              Attach the Tracefile object tfile to this trace.  The Tracefile object specifies  the  trace  file
              from   which  the  traffic  data  is  to  be  read  (see  TRACEFILE  OBJECTS  section).   Multiple
              Application/Traffic/Trace objects can be attached to the same Tracefile object.  A random starting
              place within the Tracefile is chosen for each Application/Traffic/Trace object.

       There are no configuration parameters for this object.

TRACEFILE OBJECTS

       Tracefile  objects  are  used  to  specify  the trace file that is to be used for generating traffic (see
       TRAFFIC/TRACE OBJECTS section).  $tracefile is an instance of the Tracefile Object.

       $tracefile filename trace-input
              Set the filename from which the traffic trace data is to be read to trace-input.

       There are no configuration parameters for this object.  A trace file consists  of  any  number  of  fixed
       length  records.   Each  record  consists of 2 32 bit fields.  The first indicates the interval until the
       next packet is generated in microseconds.  The second indicates the length of the next packet in bytes.

TRACE AND MONITORING METHODS

       [NOTE: This section has not been verified to be up-to-date with the release.]  Trace objects are used  to
       generate  event  level capture logs typically to an output file.  Throughout this section $ns refers to a
       Simulator object, $agent refers to an Agent object.

       $ns create-trace type fileID node1 node2 [option]
              Create a Trace object of type type and attach the filehandle fileID to it to  monitor  the  queues
              between  nodes  node1  and  node2.   type can be one of Enque, Deque, Drop.  Enque monitors packet
              arrival at a queue.  Deque monitors packet departure at a queue.  Drop monitors packet drops at  a
              queue.  fileID must be a file handle returned by the Tcl open command and it must have been opened
              for writing.  If option is not specified, the command will instruct the created  trace  object  to
              generate  ns  traces.  If  option  is """nam""" the new object will produce nam traces.  Returns a
              handle to the trace object.

       $ns drop-trace node1 node2 trace
              Remove trace object attached to the link between nodes node1 and node2 with trace  as  the  object
              handle.

       $ns trace-queue node1 node2 fileID
              Enable Enque, Deque and Drop tracing on the link between node1 and node2.

       $ns namtrace-queue node1 node2 fileID
              Same function as $ns trace-queue, except it produces nam traces.

       $ns trace-all fileID
              Enable  Enque,  Deque,  Drop Tracing on all the links in the topology created after this method is
              invoked.  Also enables the tracing of network dynamics.  fileID must be a file handle returned  by
              the Tcl open command and it must have been opened for writing.

       $ns namtrace-all fileID
              Same  function  as  $ns  trace-all, except it will produce all equivalent traces in nam format. In
              addition,  calling  this  command  before  the  simulator  starts  to  run  will  generate   color
              configurations  (if any) and topology information needed by nam (nodes, links, queues). An example
              can be found at ns-2/tcl/ex/nam-example.tcl.

       $ns namtrace-config fileID
              Assign a file to store nam configuration information, e.g., node/link/agents and  some  Simulator-
              related traces such as annotations.  When you don't want to trace every object. call this function
              and then use $ns namtrace-queue, rtModel trace, etc., to insert traces individually. Note that you
              should  use  the  same  file  for  individual traces and nam configuration. An example for this is
              available at ns-2/tcl/ex/nam-separate-trace.tcl.

       $ns monitor-queue node1 node2
              Arrange for queue  length  of  link  between  nodes  node1  and  node2  to  be  tracked.   Returns
              QueueMonitor  object  that  can  be  queried  to  learn average queue size etc.  [see QueueMonitor
              Objects section]

       $ns flush-trace
              Flush the output channels attached to all the trace objects.

       $link trace-dynamics ns fileID [option]
              Trace the dynamics of this link and write the output to fileID filehandle.  ns is an  instance  of
              the Simulator or MultiSim object that was created to invoke the simulation.

       $ns color id name
              Create  a color index, which links the number id to the color name name. All colors created before
              the simulator starts to run will be written to nam trace file, if there is any.

       $ns trace-annotate string
              Writes an annotation to ns and nam trace file, if there are any. The string should be enclosed  in
              double quote to make it a single argument.

       trace_annotate string
              Another  version  of $ns trace-annotate, which is a global function and doesn't require the caller
              to know ns.

       $ns duplex-link-op $node1 $node2 $op $args
              Perform a given operation $op on the given  duplex  link  ($node1,  $node2).   The  following  two
              operations may be used:
              orient         - Specify the nam orientation of the duplex link. Values can be
                          left, right, up, down, their mixture combined by '-' (e.g.,
                          left-down), and a number specifying the angle between the
                          link and the horizontal line.
              queuePos  - Construct a queue of the simplex link ($node1,
                          $node2) in nam, and specify the angle between the
                          horizontal line and the line along which the queued packets
                          will be displayed.

       $ns add-agent-trace agent name [fileID]
              Write  a  nam  trace  line, which will create a trace agent for agent when interpreted by nam. The
              trace agent's name will be name. This nam trace agent is used to show the position  of  agent  and
              can be used to write nam traces of variables associated with the agent.  By default traces will be
              written to the file assigned by namtrace-all.  fileID can be used to write traces to another file.

       $agent tracevar name
              Label OTcl variable name of $agent to be traced. Then whenever the variable name changes value,  a
              nam trace line will be written to nam trace file, if there is one. Note that name must be the same
              as the variable's real OTcl name.

       $ns delete-agent-trace agent
              Write a nam trace line, which will delete the nam trace associated with agent when interpreted  by
              nam.

       $agent add-var-trace name value [type]
              Write  a  nam  trace  line,  which  creates  a variable trace with name name and value value, when
              interpreted by nam. type indicates the type of the variable, e.g., is it a list, array, or a plain
              variable. Currently only plain variable is supported, for which type = 'v'.

       The following 2 functions should be called after the simulator starts running. This can be done using $ns
       at.

       $agent delete-var-trace name
              Write a nam trace line, which deletes the variable trace name when interpreted by nam.

       $agent update-var-trace name value [type]
              Write a nam trace line, which changes the value of traced variable name when interpreted  by  nam.
              Unlike $agent tracevar, the above 3 functions provide 'manual' variable tracing, in which variable
              tracing are done by placing $agent update-var-trace in OTcl  code,  while  tracevar  automatically
              generates nam traces when the traced variable changes value.

       The  tracefile  format is backward compatible with the output files in the ns version 1 simulator so that
       ns-1 post-processing scripts can still be used.  Trace records of traffic for link  objects  with  Enque,
       Deque or Drop Tracing have the following form:

                  <code> <time> <hsrc> <hdst> <packet>

       where

              <code> := [hd+-r] h=hop d=drop +=enque -=deque r=receive
              <time> := simulation time in seconds
              <hsrc> := first node address of hop/queuing link
              <hdst> := second node address of hop/queuing link
              <packet> :=  <type> <size> <flags> <flowID> <src.sport> <dst.dport> <seq> <pktID>
              <type> := tcp|telnet|cbr|ack etc.
              <size> := packet size in bytes
              <flags> := [CP]  C=congestion, P=priority
              <flowID> := flow identifier field as defined for IPv6
              <src.sport> := transport address (src=node,sport=agent)
              <dst.sport> := transport address (dst=node,dport=agent)
              <seq> := packet sequence number
              <pktID> := unique identifer for every new packet

              Only those agents interested in providing sequencing will generate sequence numbers and hence this
              field may not be useful for packets generated by some agents.

              For links that use RED gateways, there are additional trace records as follows:

                         <code> <time> <value>

              where

                     <code> := [Qap] Q=queue size, a=average queue size,
                          p=packet dropping probability
                     <time> := simulation time in seconds
                     <value> := value

              Trace records for link dynamics are of the form:

                         <code> <time> <state> <src> <dst>

              where

                     <code> := [v]
                     <time> := simulation time in seconds
                     <state> := [link-up | link-down]
                     <src> := first node address of link
                     <dst> := second node address of link

INTEGRATOR Objects

       Integrator Objects support the approximate computation of continuous integrals using discrete sums.   The
       running  sum(integral)  is computed as: sum_ +=  [lasty_ * (x - lastx_)] where (x, y) is the last element
       entered and (lastx_, lasty_) was the element previous to that added to the sum.  lastx_  and  lasty_  are
       updated  as  new  elements  are  added.   The first sample point defaults to (0,0) that can be changed by
       changing the values of (lastx_,lasty_).

       $integrator newpoint x y
              Add the point (x,y) to the sum.  Note that it does not make sense for x to be less than lastx_.

       There are no configuration parameters specific to this object.

       State Variables

              lastx_ x-coordinate of the last sample point.

              lasty_ y-coordinate of the last sample point.

              sum_   Running sum (i.e. the integral) of the sample points.

SAMPLES Objects

       Samples Objects support the computation of mean and variance statistics for a given sample.

       $samples mean
              Returns mean of the sample.

       $samples variance
              Returns variance of the sample.

       $samples cnt
              Returns a count of the sample points considered.

       $samples reset
              Reset the Samples object to monitor a fresh set of samples.

       There are no configuration parameters or state variables specific to this object.

BUILTINS

       [NOTE: This section has not been verified to be up-to-date with the release.]  Because OTcl  is  a  full-
       fledged  programming  language,  it  is  easy  to  build  high-level  simulation  constructs  from the ns
       primitives.  Several library routines have been  built  in  this  way,  and  are  embedded  into  the  ns
       interpreter  as  methods  of  the  Simulator  class.   Throughout this section $ns represents a Simulator
       object.

       $ns create-connection srcType srcNode dstType dstNode class
              Create a source agent of type srcType at node srcNode and connect it to  a  destination  agent  of
              type  dstType  at  node  dstNode.   Also,  connect the destination agent to the source agent.  The
              traffic class of both agents is set to class.  This method returns the source agent.

EXAMPLE

           set ns [new Simulator]

           #
           # Create two nodes
           #
           set n0 [$ns node]
           set n1 [$ns node]

           #
           # Create a trace and arrange for all the trace events of the
           # links subsequently created to be dumped to "out.tr"
           #
           set f [open out.tr w]
           $ns trace-all $f

           #
           # Connect the two nodes with a 1.5Mb link with a transmission
           # delay of 10ms using FIFO drop-tail queuing
           #
           $ns duplex-link $n0 $n1 1.5Mb 10ms DropTail

           #
           # Set up BSD Tahoe TCP connections in opposite directions.
           #
           set tcp_src1 [new Agent/TCP]
           set tcp_snk1 [new Agent/TCPSink]
           set tcp_src2 [new Agent/TCP]
           set tcp_snk2 [new Agent/TCPSink]
           $ns attach-agent $n0 $tcp_src1
           $ns attach-agent $n1 $tcp_snk1
           $ns attach-agent $n1 $tcp_src2
           $ns attach-agent $n0 $tcp_snk2
           $ns connect $tcp_src1 $tcp_snk1
           $ns connect $tcp_src2 $tcp_snk2

           #
           # Create ftp sources at the each node
           #
           set ftp1 [$tcp_src1 attach-source FTP]
           set ftp2 [$tcp_src2 attach-source FTP]

           #
           # Start up the first ftp at the time 0 and
           # the second ftp staggered 1 second later
           #

           $ns at 0.0 "$ftp1 start"
           $ns at 1.0 "$ftp2 start"

           #
           # run the simulation for 10 simulated seconds
           #
           $ns at 10.0 "exit 0"
           $ns run

DEBUGGING

       To enable debugging when building ns from source:
           % ./configure --enable-debug
           % make

       For more details about ns debugging please see <http://www-mash.cs.berkeley.edu/ns/ns-debugging.html>.

DIFFERENCES FROM NS-1

       In general, more complex objects in ns-1 have been  broken  down  into  simpler  components  for  greater
       flexibility and composability.  Details of differences between ns-1 and ns-2 can be found at <http://www-
       mash.cs.berkeley.edu/ns/ns.html>.

HISTORY

       Work  on  the  LBL  Network  Simulator  began  in  May   1990   with   modifications   to   S.   Keshav's
       (keshav@research.att.com) REAL network simulator, which he developed for his Ph.D. work at U.C. Berkeley.
       In Summer 1991, the simulation description language was revamped, and later, the NEST threads  model  was
       replaced  with  an  event  driven framework and an efficient scheduler.  Among other contributions, Sugih
       Jamin (jamin@usc.edu) contributed the calendar-queue  based  scheduling  code  to  this  version  of  the
       program,  which  was  known  as  tcpsim.  In December 1994, McCanne ported tcpsim to C++ and replaced the
       yacc-based simulation description language with a Tcl interface, and added preliminary multicast support.
       Also  at  this  time,  the  name  changed from tcpsim to the more generic ns.  Throughout, Floyd has made
       modifications to the TCP code and  added  additional  source  models  for  her  investigations  into  RED
       gateways,  resource  management, class-based queuing, explicit congestion notification, and traffic phase
       effects.   Many  of  the  papers  discussing  these  issues  are  available   through   URL   http://www-
       nrg.ee.lbl.gov/.

SEE ALSO

       Tcl(1), tclsh(1), nam(1), otclsh

       [1]    S.  Keshav,  ``REAL:  A  Network  Simulator''.   UCB  CS  Tech  Report 88/472, December 1988.  See
              http://minnie.cs.adfa.oz.au/REAL/index.html for more information.

       [2]    Floyd, S. and Jacobson, V.  Random Early Detection gateways for  Congestion  Avoidance.   IEEE/ACM
              Transactions on Networking, Vol. 1, No. 4.  August 1993.  pp. 397-413.  Available from http://www-
              nrg.ee.lbl.gov/floyd/red.html.

       [3]    Floyd, S.  Simulator Tests.  July 1995.  URL ftp://ftp.ee.lbl.gov/papers/simtests.ps.Z.

       [4]    Floyd,  S.,  and  Jacobson,  V.   On  Traffic   Phase   Effects   in   Packet-Switched   Gateways.
              Internetworking: Research and Experience, V.3 N.3, September 1992.  pp. 115-156.

       [5]    Floyd,  S.,  and  Jacobson,  V.   Link-sharing and Resource Management Models for Packet Networks.
              IEEE/ACM Transactions on Networking, Vol. 3 No. 4, August 1995.  pp. 365-386.

       [6]    Floyd, S., Notes of Class-Based Queueing: Setting  Parameters.   URL  ftp://ftp.ee.lbl.gov/papers/
              params.ps.Z.  September 1995.

       [7]    Fall,  K.,  and  Floyd,  S.  Comparisons of Tahoe, Reno, and Sack TCP.  December 1995.  URL ftp://
              ftp.ee.lbl.gov/papers/sacks.ps.Z.

       [8]    David  Wetherall  and  Christopher  J.  Linblad.   Extending  Tcl  for   Dynamic   Object-Oriented
              Programming.  In Proceedings of the USENIX Tcl/Tk Workshop, Toronto, Ontario, USENIX.  July, 1995.
              At <http://www.tns.lcs.mit.edu/publications/tcltk95.djw.html>.

       [9]    M. Shreedhar and G. Varghese. Efficient Fair Queueing Using  Deficit  Round  Robin.  In  Proc.  of
              SIGCOMM, pp. 231-242, 1995.

       [10]   Hoe,  J.,  Improving the Start-up Behavior of a Congestion Control Scheme for TCP.  in SIGCOMM 96,
              August 1996, pp. 270-280.  URL http://www.acm.org/sigcomm/sigcomm96/papers/hoe.html.

       [11]   Fall,  K.,  Floyd,  S.,  and  Henderson,  T.,  Ns  Simulator  Tests   for   Reno   FullTCP.    URL
              ftp://ftp.ee.lbl.gov/papers/fulltcp.ps.  July 1997.

       [12]   Floyd, S., Jacobson, V., Liu, C.-G., McCanne, S. and Zhang, L., A Reliable Multicast Framework for
              Light-weight Sessions and  Application  Level  Framing.  To  appear  in  IEEE/ACK  Transaction  on
              Networking, November 1996.  ftp://ftp.ee.lbl.gov/papers/srm1.ps.gz

       [13]   Fall,  K.,  and Varadhan, K., (eds.), "Ns notes and documentation", work in progress.  http://www-
              mash.cs.berkeley.edu/ns/nsDoc.ps.gz

       Research using ns is on-going.  A list of recent research contributions employing  ns  can  be  found  at
       <http://www-mash.cs.berkeley.edu/ns/ns-research.html>.

       Work  on  ns  is  on-going.   Information  about  the  most  recent  version is available at <http://www-
       mash.cs.berkeley.edu/ns/ns.html>.

       A  mailing  list  for  ns  users  and  announcements  is  also  available,   send   mail   to   ns-users-
       request@mash.cs.berkeley.edu  or  ns-announce-request@mash.cs.berkeley.edu  to join.  Questions should be
       forwarded to ns-users; ns-announce will be low-traffic announcements only.

AUTHORS

       Steven McCanne (mccanne@ee.lbl.gov), University of California, Berkeley and  Lawrence  Berkeley  National
       Laboratory,  Berkeley,  CA,  and  Sally  Floyd  (floyd@ee.lbl.gov) Lawrence Berkeley National Laboratory,
       Berkeley, CA.  A complete list  of  contributors  to  ns  is  at  <http://www-mash.cs.berkeley.edu/ns/ns-
       contributors.html>.

BUGS

       Not all of the functionality supported in ns-1 has been ported to ns-2.

       This manual page is incomplete.

                                                  25 July 1997                                             NS(1)