We simulated different routing protocols by simple replace the value of "$NS_PROTO" and "$NS_PROTO_SCRIPT" in the "run-setup" file. The others protocols such as DSDV, DSR and AODV are OK, but the TORA could not run. It continued to print the error message like the following:

        Hacked for tora20 runs!! No RTR revc trace

This is not actually an error message. Because the TORA code sends so many packets and produces such large trace files, I had to remove all but the critically required logging agents in order to keep the size of the files managable.

mobile-node.tcl prints out that warning so I'd remember why there wasn't any data recorded by the RTR receive tracer.

I found some documentation on your page, but I want to look deeper into the code. So please let me know if there is any object-diagram or object-communication-diagram about the programs.

I'm afraid the ns document on our web page is the only documentation that exists outside of the code and its comments. You'll also want to read through the ns documentation from the VINT website to understand the basic ns system.

In general, the easiest way to understand one of the modules is to start reading the code at the recv() function.

I see that some wireless files are present in the main VINT ns release. Are those all of the CMU extensions?

I get compile errors like

cmu/adhockey-slaver.cc:  In method `AdHockeySlaver::AdHockeySlaver()':
adhockey-slaver.cc:53: `struct sockaddr_in' has no member named `sin_len'

As a System V extract, Linux doesn't define a sa_len for the struct sockaddr. You can comment out this line, and things will compile fine. Be advised that the emulation code doesn't work on Linux, due to limitations with libpcap. We're looking for an OS independent interface to BPF and raw sockets.

We encounter the following err or message while simulating DSDV:

ns:cmu/dsdv/dsdv.cc:122:void DSDV TriggerHandler::handle(class Event*): Assertion `prte && prte->trigger_event == e' failed.
Abort (core dumped)
Error: ns on logs/out-1000x1000-50-1-15-1-cbr-50-10-4-512

There is a bug somewhere in the implementation of DSDV that causes the event timers to get into an inconsistent state. When this happens, the assertions detect it and stop the simulation before any bad data can be generated.

In the past I've spent a bit of time looking for this bug, but haven't found it, so I've notified the architect of the DSDV code (Yih-Chun Hu yihchun@cs.cmu.edu). If either of you can find and kill the bug, I'd be grateful for your patches. Currently, simply changing the seed of the simulation or the movement pattern is often enough to keep the DSDV implementation from entering this infrequent bad state.

ad-hockey

Is there a version of ad-hockey that will run with the current Perl/Tk?

"open2 : exec of what-time failed at ./ad-hockey line 1640"

As described in the ad-hockey manual, you must type

make
what-time

This error message arises because the system is unable to find and execute the what-time program, upon which the ad-hockey script depends for telling it what the current time is.

ad-hockey dies with a DFU error when replaying traces? I ran the simulator's output trace file through viz-trace like the instructions said to....

DFU: unknown event:
s 1.316136379 _22_ MAC  --- 0 MAC 44 [1b 28f d 16 0] 

Died at /home/tyan/work/ns-allinone-2.1b5/bin/ad-hockey line 1521,
 chunk 1096.

<    if (/^[srf] /) {
>    if (/^[srf] / && !/MAC/) {

When I try to complile Perl/Tk 400.200 it complains about Perl_gv_fullname as in

tkGlue.c: In function `LangCatArg':
tkGlue.c:205: too many arguments to function `Perl_gv_fullname'
tkGlue.c:215: too many arguments to function `Perl_gv_fullname'
make: *** [tkGlue.o] Error 1
[root@bpvanle Tk400.200]# exit

I do recall having a problem with compiling Perl/Tk400.200 on some
platforms, and recall a quick read through tkGlue.c found the cause.
At the top of my tkGlue.c I have:

#include 
#if 0
#if PATCHLEVEL > 3 || SUBVERSION >= 4
#define Tkgv_fullname(x,y,z) gv_fullname(x,y,z)
#else
#define Tkgv_fullname(x,y,z) gv_fullname(x,y)
#endif
#else
/* -dam 2/8/98 */
#define Tkgv_fullname(x,y,z) gv_fullname(x,y)
#endif

If this suggested change doesn't work, a few greps for
'_fullname' should discover and enable you to fix the problem.

Is that possible for me to convert the output files generated by the run.tcl (*.tr) to a *.nam format? If so, how?

No. NAM is the VINT visualizer, and it doesn't know how to represent mobility yet. For the momment, you will need to use ad-hockey, the visualizer provided with the CMU extensions.

After I make what-time I move ad-hockey, viz-trace and what-time to my favorite executable directory. How do I run ad-hockey however? Is that by the command ./ad-hockey , and ./viz-trace ? When I did that I get the error message ``No such file or directory'' ?

Just to be clear, if you have installed the files into other than the current directory, you can't run the programs by typing ``./ad-hockey'' You'll have to either put the directory where the programs are located on your search path, or type the full path to the executable.

I'm guessing the problem is actually that perl v5 isn't installed in /usr/local/bin where the ad-hockey script expects it. Either make a symlink in /usr/local/bin to /usr/bin/perl, or change the first line in ad-hockey. (Is there a good way to get a perl script to locate where the perl interpreter lives? I can imagine a cheap shell hack that finds the interpreter and then execs it, but someone must have solved this already.)

Support Utilities

I use Ad-Hockey to generate a scenario file. Do I need to use cmu/setdest/emulate to create an operational scenario file for NS. The files I create with just Ad-Hockey have a different form than those you provide.

The movement pattern files and communication pattern files created by
ad-hockey can be directly fed into the ns simulation using the -cp
and -sc flags to run.tcl

The scenario files we provide look different since they were
automaticly generated by the setdest program, which uses the random
waypoint model described in our MobiCom 98 paper.  The output of
setdest is annotated with the the ``god'' information that describes
the length of the shortest path between any two nodes at any point in
time.  If you would like to perform shortest-path analysis on your
manually created scenarios, you can run the movement pattern (aka a
scenario file) you created with ad-hockey through the calcdest program
(ns/ns-src/cmu/setdest/calcdest) which will annotate the file with the
``god'' information.


usage: ./calcdest       [-n ] 
            [-t ]
            -i  -o 

            #nodes, max time, and range read from scenario file if possible

What are emulate and the macfilter used for?

emulate and macfilter are for use in emulating the connection patterns of a physical ad hoc network. We use it for in-lab debugging and regression testing of our implementation of DSR. In order to use it you need real machines with real interfaces running a kernel with a real implementation of the ad hoc routing protocol. As described in the ad-hockey docs, it allows you to draw a movement pattern on the screen with ad-hockey, and then cause the machines to behave as though they had radio connectivity as you drew on the screen, even though they are all in physical radio range of each other. There is some more information in the ad-hockey User's Guide.

Data Analysis

I am getting the error,

Actual RT Length while using totals.pl ,for performance comparison of wireless protocols. Is this normal for a run,or is there some error.

Some messages of this form are normal, as the optimal path length is set in the header of the packet when it is originated, based on the information in the scenario file. Since the nodes can move during the time the packet is traversing the network (particularily when there is congestion causing large router queues), the packet can arrive over a shorter path than existed when the packet was originated.

Large number of these messages usually mean the propagation model used in the simulation is different than the one used in calculating the optimal path lengths when creating the scenario.

I was wondering how you had been able to trace the average node degree in the simulation work for DSR described in "The effects of on- demand behavior in routing protocols for multi-hop wireless ad hoc networks". We are trying to create networks of varying node degrees and observe some of DSR's behavior but am very curious now how you had determined the average node degrees (16.5 for the square area and 11.5 for the rectangle area - as I remember from reading...).

Turn on MAC tracing. For each broadcast packet sent, count up the MAC layer recvs. bc-tally.pl may be a helpful starting place. For better estimates, consider using a special traffic load with lots of broadcasts, or altering calcdest to track the node degree.

What tools were used for the analysis in the Mobicom '98 paper?

For analysis, we used a large variety of scripts and grep expressions. Most of the Mobicom '98 plots came from processing the totals files into a format Matlab could read, and then doing the remainder of the analysis there. See totals.{csh,pl} and post-totals.{csh.pl} in ns-src/cmu/scripts for the scripts. Running any of the scripts w/o arguments should tell you what arguments it expects. Please be advised that most of the spew that totals.pl and post-totals.pl spit out can be ignored. However, the validation of any data you produce is up to you.

• totals.pl takes a single trace file and ``totals up'' how many packets of each type were sent. For example:

  totals.pl out.tr RTR 50 > totals.rtr
  

  counts up the packets seen at the RTR level tracers.
• totals.csh runs totals.pl on all the simulations specified in run-setup
• post-totals.pl post-processes the output of totals into a form that can be read by matlab

  post-totals.pl totals.rtr RTR DSR > sum_rtr
  

• post-totals.csh runs post-totals.pl on all the simulations specified in run-setup

My trace files are huge!

Yep. We have 3 18GB disks we fill regularily when doing many runs. The remote logging options to run.csh are helpful for organizing a ``farm'' of machines with small disks running the simulations and directing the outputs to a collection machine with a large disk. You may also reduce the amount of trace data collected by turning off logging you don't need. For example, see run.tcl to turn off tracing at the MAC, RTR, or AGT layer (often MAC tracing can be turned off if you are interested in only network layer events). Many C++ source files also have a

static const int verbose = 1 

Luckily, disk space keeps getting cheaper, though backing up ``good'' runs to tape is still a real pain for which we don't have a good solution.

I need reproduce the results your group presented in MobiComm 98. Namely the %packets delivered, overhead and path optimality.

Unfortunately, if you don't have the time to really read through the code and figure out what's going on, you shouldn't be messing with simulators. They're guaranteed to give you answers, but it's on your head to make sure the answers mean something, and validating the answers is what actually takes the most time.

What scripts were involved in retreving the number of packets sent...

My recollection is that all the MobiCom'98 data can be retrieved from the file produced by totals.pl.

If you use run-setup to describe your simulation run, then

run.csh -auto

will do all the simulations, and

totals.csh

will run totals on all the trace files.

You will need to think about and understand which packets are logged by which tracers in order to interpret the difference between the numbers in the AGT, RTR, and MAC totals files. See the diagram in the manual for our extensions.

Also do the verbose_ switches need to be on, or were these just prints for your debugging?

The packet counts in totals are based solely on packets going through the tracers, and so don't depend on the verbose flags. The verbose flags are for getting extra information about the protocols and disecting their performance to understand why we're getting the results we're getting.

Configuring and Setting Up Simulations

By null-MAC do u mean ignoring collisions and contention? or the ideal mac probably with central arbitration which has no collisions?

MAC/Null ignores collisions and contention. Every packet sent with enough energy to be received by the receiver will be received. All offered packets are sent after a constant delay (no contention).

Does the wavelan MAC in the simulator conform to the latest WaveLan Specs?

The 802.11 MAC is already pretty close to the WaveLAN-IEEE (aka WaveLAN-2) specs. CSMA/CA WaveLAN implements the WaveLAN-1 MAC protocol designed by the WaveLAN builders.

What is each node's transmission radius set to? and which C++ module can it be found in ?

The nominal range in the snapshot is 250m. The exact ``range'' of any particular transmission depends on the location and number of other concurrent transmitters (since they interfere with each other).

The constants that control the range, if you crank the math, are in run.tcl. In the newest (?) snapshot's run.tcl is a function that given a ``nominal range:'' in the scenario file reverse engineers the power constants. Think carefully if you tweak this knob (e.g., the egg is on your face if you request a xmit power that'll fry birds). Also be aware that 802.11 stops working at much more than a 2km range (there isn't enough time for the RTS/CTS exchange to complete before the offical timeout). The WaveLAN MAC will continue to work past this range.

I would like to know how can I set the TCP sources in-active in the simulation? As I checked with RUN.TCL, there is a setting for "Agent/TCP set packetSize_ 14 60", however, I could not find where the main switch for not deactivating the TCP in the simulation. (I also checked with RUN-SETUP, DSR.TCL...)

The communication pattern is dictated by the communication pattern file provided as input to the simulation using the -cp command line argument. If that file doesn't list any TCP sources, none are used during the simulation. Since there is no traffic by default, there's no global switch to turn anything off.

I would like to know in which file(s) can I change the constants used in a protocol simulation? (For example, DSR -- Time between retransmitted ROUTE REQUESTS, Size of source route header carrying "n" addresses, Timeout for nonpropagating search...)

Before you change the value of the constants, you'll want to read and understand how they are used in the code. As always, variables aren't always named for exactly what they do, or their use shifts over time from when they're first created. Using grep to look for all occurrences of the constant is a great help. Start by reading through the header files and main .cc files in each of the protocol directories. eg:

bush dsr % grep -n arp_timeout *.{cc,h}
dsragent.cc:45:Time arp_timeout = 30.0e-3;      // (sec) arp request timeout
dsragent.cc:1165:         delay += arp_timeout;
constants.h:14:extern Time arp_timeout; // (sec) arp request timeout

In wireless extension, if a node want to broadcast a packet whose destination is "dst" to all its neighbors, the "des_" in ip header must be set as "dst", then how I set the "next_hop" in the struct hdr_cmn, 0 or IP_BROADCAST?

The 8/5/99 release of the wireless-extensions manual provides a brief description of writing packet sources. In sum, you would set the next_hop to IP_BROADCAST, and type to AF_INET. This will work correctly if done at the ``network layer'' for packets being handed to the link layer. For examples, you can read the provided routing protocols to see how they create the broadcast packets they send out. Please beware that none of the routing modules we provided will interpret an IP destination address of IP_BROADCAST as meaning the packet should be broadcast locally. They simply haven't had that functionality put in them. If you decide to add this functionality, please send me your patches and some short example code and I will include it in the next release.

Dynamic Source Routing Questions

2. Does your code actually make use of piggybacking, thus reducing the total number of packets.

The simulator does not implement the general structure described in the Internet Draft. This is a result of historical accident and a (mistaken) belief that the system currently in use would be simplier to program.

Currently, the sr header (cmu/dsr/hdr_sr.cc) in the simulator can represent simultaneously carrying (a single Route Request XOR a single source route), a single Route Reply, and a nested series of Route Errors.

The simulator uses piggybacking, though not as extensively as it could. In particular, DSR control messages are not piggybacked onto data packets. Piggybacking can be more than an optimization, for example, when launching a Route Request to find a route with with to return a Route Reply, correctness requires that the Route Reply be piggybacked on the Route Request.

1. If node A overhars a route M N O (P) Q R, DSR adds route A P Q R to its cache. Why does it not cache the reverse route A P O N M?

2. Why are the _reverse_ routes in route requests and data packets being forwarded, not cached at intermediate nodes?

The code is currently (10/27/99) schizophrenic on the issue of how much to believe that links are bidirectional. The code originally assumed that many links would be unidirectional, and was all written and working for that assumption. 802.11, as used in the simulator, requires that a link be bidirectional before data can be passed across it (since an ACK must be returned directly to the transmitter by the receiver). When we added the 802.11 MAC layer for the MobiCom'98 paper, not all possible optimizations were made in the DSR code to leverage the new bidirectional assumption. I would expect performance to go up if the additional optimizations were made. As it sez in the code:

bool dsragent_require_bi_routes = true;
// do we need to have bidirectional source routes? 
// [XXX this flag doesn't control all the behaviors and code that assume
// bidirectional links -dam 5/14/98]

3. The primary and secondary caches store routes passing through me and overheard routes, respectively. But both the caches are fetched while searching for routes . What is the key motivation for having two separate caches? Are they maintained differently in any other way?

Node N stores in its primary cache is routes that it did discovery for, or has used to send packets. Routes that are overheard, or otherwise learned oportunistically are stored into the secondary cache. When we fetch a route, we search both caches, and if the best route is found in the secondary cache, it is promoted to the primary cache.

Both caches use round-robin replacement, but with independent victim pointers. Having two caches prevents oportunistially learned routes from flushing routes that N is actually using, since turnover in the secondary cache is higher than in the primary cache (i.e., the victim pointer cycles more frequently). Clearly a wide range of other cache algorithms and data structures are possible. For example, we also have a ``link-state'' cache, but we haven't tried things such as implementing LRU policy in the ``mobicache''.

Misc.

When I run the totals.csh, it appers to have some problems. It cannot find the totals.pl file. the command line are as follow

                ~/ns2> ./cmu/scripts/totals.csh

                   unzipping out-xxxxxxxxxxxxx
                   totals.pl: command not found

This is a basic UNIX usage issue. You will need to learn about search paths, and how UNIX looks for executables.

Hints:
  set path = ($path mumble )
or
  fully qualified path name in totals.csh

I have also tried out the run.tcl and run.csh as mentioned in the document. It appears the simulations are alright. the command lines are

       ~ns2> ./cmu/scripts/run.csh -auto

       NS EXITING
       Num events : 5915926            Max. scheduler: 72110
       113.250u  1.430s   2:10.37   87.9%  0+0k   0+0io 278pf+0w

I apologize for my rudeness, but if you are going to work with this code, you are going to have to make a much greater effort to read and understand it on your own. Please carefully read run.csh. It uses the time (1) command. Read the manual page for time (e.g., man time). Grep the ns source code for the string ``Num events'' to find where it is printed from. Read and understand the code around it.

sorry for annoying again , i just have a question ? how can i modify the source code of TCP protocol ? is the TCP agent included in ns is a file that can be edited ? if yes what is the file name and in what language it is written ? if not how i can modify the current version of TCP for evaluation