trace.tex

柯老师网站上找到的

                size_ += pktsz;
                pkts_++;
                if (bytesInt_)
                        bytesInt_->newPoint(now, double(size_));
                if (pktsInt_)
                        pktsInt_->newPoint(now, double(pkts_));
                if (delaySamp_)
                        hdr->timestamp() = now;
                if (channel_)
                        printStats();
        \}

        \ldots \fcn[]{in}, \fcn[]{out}, \fcn[]{drop} are all defined similarly \ldots
\end{program}
It addition to the packet and byte counters, a queue monitor
may optionally refer to objects that keep an integral
of the queue size over time using
\code{Integrator} objects, which are defined in Section\ref{sec:integral}.
The \code{Integrator} class provides a simple implementation of
integral approximation by discrete sums.

All bound variables beginning with {\bf p} refer to packet counts, and
all variables beginning with {\bf b} refer to byte counts.
The variable {\tt size\_} records the instantaneous queue size in bytes,
and the variable {\tt pkts\_} records the same value in packets.
When a \code{QueueMonitor} is configured to include the integral
functions (on bytes or packets or both), it
computes the approximate integral of the
queue size (in bytes)
with respect to time over the interval $[t_0, now]$, where
$t_0$ is either the start of the simulation or the last time the
\code{sum\_} field of the underlying \code{Integrator} class was reset.

The \code{QueueMonitor} class is not derived from \code{Connector}, and
is not linked directly into the network topology.
Rather, objects of the \code{SnoopQueue} class (or its derived classes)
are inserted into the network topology, and these objects contain references
to an associated queue monitor.
Ordinarily, multiple \code{SnoopQueue} objects will refer to the same
queue monitor.
Objects constructed out of these classes are linked in the simulation
topology as described above and call \code{QueueMonitor}
\code{out}, \code{in}, or \code{drop} procedures,
depending on the particular type of snoopy queue.

\section{Per-Flow Monitoring}
\label{sec:flowmon}

A collection of specialized classes are used to to implement
per-flow statistics gathering.
These classes include: \\
\code{QueueMonitor/ED/Flowmon},
\code{QueueMonitor/ED/Flow}, and \code{Classifier/Hash}.
Typically, an arriving packet is inspected to determine
to which flow it belongs.
This inspection and flow mapping is performed by a {\em classifier}
object (described in section \ref{sec:flowmonitor}).
Once the correct flow is determined, the packet is passed to
a {\em flow monitor}, which is responsible for collecting per-flow
state.
Per-flow state is contained in {\em flow} objects in a one-to-one
relationship to the flows known by the flow monitor.
Typically, a flow monitor will create flow objects on-demand when
packets arrive that cannot be mapped to an already-known flow.

\subsection{The Flow Monitor}
\label{sec:flowmonitor}

The \code{QueueMonitor/ED/Flowmon} class is responsible for managing
the creation of new flow objects when packets arrive on previously
unknown flows and for updating existing flow objects.
Because it is a subclass of \code{QueueMonitor}, each flow monitor
contains an aggregate count of packet and byte arrivals, departures, and
drops.
Thus, it is not necessary to create a separate queue monitor to record
aggregate statistics.
It provides the following OTcl interface:
\begin{quote}
\begin{tabularx}{\linewidth}{rX}
         classifier & get(set) classifier to map packets to flows\\
         attach & attach a Tcl I/O channel to this monitor\\
         dump  & dump contents of flow monitor to Tcl channel\\
         flows & return string of flow object names known to this monitor\\
\end{tabularx}
\end{quote}

The {\tt classifier} function sets or gets the name of the previously-allocated
object which will perform packet-to-flow mapping for the flow monitor.
Typically, the type of classifier used will have to do with the notion of
``flow'' held by the user.
One of the hash based classifiers that inspect various IP-level header
fields is typically used here (e.g. fid, src/dst, src/dst/fid).
Note that while classifiers usually receive packets and forward them
on to downstream objects, the flow monitor uses the classifier only for
its packet mapping capability, so the flow monitor acts as a passive
monitor only and does not actively forward packets.

The {\tt attach} and {\tt dump} functions are used to
associate a Tcl I/O stream with the
flow monitor, and dump its contents on-demand.
The file format used by the {\tt dump} command is described below.

The {\tt flows} function returns a list of the names of flows known
by the flow monitor in a way understandable to Tcl.
This allows tcl code to interrogate a flow monitor in order
to obtain handles to the individual flows it maintains.

\subsection{Flow Monitor Trace Format}
\label{sec:flowmonclass}

The flow monitor defines a trace format which may be used by post-processing
scripts to determine various counts on a per-flow basis.
The format is defined by the folling code in \nsf{flowmon.cc}:
\begin{program}
void
FlowMon::fformat(Flow* f)
\{   
        double now = Scheduler::instance().clock();
        sprintf(wrk_, "%8.3f %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d 
%d", 
                now,    
                f->flowid(),    // flowid
                0,              // category
                f->ptype(),     // type (from common header) 
                f->flowid(),    // flowid (formerly class)
                f->src(),
                f->dst(),
                f->parrivals(), // arrivals this flow (pkts)
                f->barrivals(), // arrivals this flow (bytes) 
                f->epdrops(),   // early drops this flow (pkts)
                f->ebdrops(),   // early drops this flow (bytes) 
                parrivals(),    // all arrivals (pkts)
                barrivals(),    // all arrivals (bytes) 
                epdrops(),      // total early drops (pkts)
                ebdrops(),      // total early drops (bytes) 
                pdrops(),       // total drops (pkts)
                bdrops(),       // total drops (bytes) 
                f->pdrops(),    // drops this flow (pkts) [includes edrops] 
                f->bdrops()     // drops this flow (bytes) [includes edrops]
        );
\};  
\end{program}
Most of the fields are explained in the code comments.
The ``category'' is historical, but is used to maintain loose backward-
compatibility with the flow manager format in \ns~version 1.

\subsection{The Flow Class}
\label{sec:flowclass}

The class \code{QueueMonitor/ED/Flow} is used by the flow monitor
for containing per-flow counters.
As a subclass of \code{QueueMonitor}, it inherits the standard
counters for arrivals, departures, and drops, both in packets and
bytes.
In addition, because each flow is typically identified by
some combination of the packet source, destination, and flow
identifier fields, these objects contain such fields.
It's OTcl interface contains only bound variables:
\begin{quote}
\begin{alist}
        \code{src\_} &   source address on packets for this flow\\
        \code{dst\_} &   destination address on packets for this flow\\
        \code{flowid\_} & flow id on packets for this flow\\
\end{alist}
\end{quote}

Note that packets may be mapped to flows (by classifiers) using
criteria other than a src/dst/flowid triple.
In such circumstances, only those fields actually used by
the classifier in performing the packet-flow mapping should be
considered reliable.


\section{Commands at a glance}
\label{sec:tracecommand}

Following is a list of trace related commands commonly used in
simulation scripts:
\begin{flushleft}
\code{$ns_ trace-all <tracefile>}\\
This is the command used to setup tracing in ns. All traces are written in
the <tracefile>.


\code{$ns_ namtrace-all <namtracefile>}\\
This command sets up nam tracing in ns. All nam traces are written in to
the <namtracefile>.


\code{$ns_ namtrace-all-wireless <namtracefile> <X> <Y>}\\
This command sets up wireless nam tracing. <X> and <Y> are the x-y co-ordinates
for the wireless topology and all wireless nam traces are written  into
the <namtracefile>.


\code{$ns_ nam-end-wireless <stoptime>}\\
This tells nam the simulation stop time  given in <stoptime>.


\code{$ns_ trace-all-satlinks <tracefile>}\\
This is a method to trace satellite links and write traces into <tracefile>.


\code{$ns_ flush-trace}\\
This command flushes the trace buffer and is typically called before the
simulation run ends.


\code{$ns_ get-nam-traceall}\\
Returns the namtrace file descriptor stored as the Simulator instance
variable called \code{namtraceAllFile_}.


\code{$ns_ get-ns-traceall}\\
Similar to get-nam-traceall. This returns the file descriptor for ns tracefile
which is stored as the Simulator instance called \code{traceAllFile_}.


\code{$ns_ create-trace <type> <file> <src> <dst> <optional:op>}\\
This command creates a trace object of type <type> between the <src> and
<dst> nodes. The traces are written into the <file>. <op> is the argument
that may be used to specify the type of trace, like nam. if <op> is not
defined, the default trace object created is for nstraces.


\code{$ns_ trace-queue <n1> <n2> <optional:file>}\\
This is a wrapper method for \code{create-trace}. This command creates a
trace object for tracing events on the link represented by the nodes <n1>
and <n2>.


\code{$ns_ namtrace-queue <n1> <n2> <optional:file>}\\
This is used to create a trace object for namtracing on the link between
nodes <n1> and <n2>. This method is very similar to and is the namtrace
counterpart of method \code{trace-queue}.


\code{$ns_ drop-trace <n1> <n2> <trace>}\\
This command makes the given <trace> object a drop-target for the queue
associated with the link between nodes <n1> and <n2>.


\code{$ns_ monitor-queue <n1> <n2> <qtrace> <optional:sampleinterval>}\\
This sets up a monitor that keeps track of average queue length of the queue
on the link between nodes <n1> and <n2>. The default value of
sampleinterval is 0.1. 


\code{$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. 

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

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

where 
\begin{verbatim}
<code> := [hd+-] 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 
\end{verbatim}

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 \\
\begin{verbatim}
<code> := [Qap] Q=queue size, a=average queue size, p=packet dropping
probability
<time> := simulation time in seconds 
<value> := value 
\end{verbatim}

Trace records for link dynamics are of the form: \\

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

where \\
\begin{verbatim}
<code> := [v]
<time> := simulation time in seconds 
<state> := [link-up | link-down]
<src> := first node address of link 
<dst> := second node address of link 
\end{verbatim} 
\end{flushleft}


\endinput