Why We Chose Parsec over NS
We carefully
evaluated and compared NS and Parsec before we made our final decision to
use Parsec as the simulation language for our AWC simulation. Our
decision was based on several important factors, outlined below:
- Parsec (the next generation of Maisie) scales much better than NS
since it is specifically designed to allow one to write a simulation that
can be run on MPP's, NOW's, etc. This allows Parsec to support simulations
with potentially thousands of nodes. We thought this was an important
fundamental advantage that Parsec offers over NS since one can not
necessarily interpolate the results of a small scale simulation to predict
a protocol's behavior in a large-scale topology.
- Parsec is well-suited for our simulation since it offers good support
for high-level (application level) simulations (it offers a very nice,
easy, and clean message passing infrastructure). It seemed to us that NS
is currently geared more towards low-level protocol simulations, and it
seemed to provide minimal support our simulation. NS is great for
monitoring and analyzing packet traces and queue behavior, but we are not
interested in these low-level details.
- Although we were aware at the time of our decision that NS offers
superior networking modules (accurate TCP, mcast, etc. modules), we also
realized that an extensive effort was underway to add similar modules to
Parsec. In fact, the main modules from each of the classical ISO-OSI
7-layer protocol stack now exist for Parsec (this includes, TCP, IP,
DVMRP, etc). This effort continues with RSVP and oher modules currently
being developed. (I'm not sure if they are currently working on any traffic
generators, but I don't see why they couldn't do this if they wanted to.)
We plan to integrate these new modules into our current simulation in the
future. We also plan to see if we can interface a topology generator to
our simulation (and perhaps Parsec in general) and use actual web traffic
data to drive our simulation.
- Although we were also aware that NS offers a Network Animator (NAM),
we didn't think that this provided any advantage; for it seems that NAM
animates packet traces generated from NS simulations. Since we are not
interested in such low-level details, we did not see any usefulness from
NAM (In addition, very little documentation on NAM existed at the time.
In fact, they were not even releasing the NAM software then). We were more
interested in building a GUI that would allow us to graphically view and
analyze the behavior of the CGMP and CRP protocols in an intuitive,
efficient, and effective manner. As an aside, the Parsec group is
currently working on a general GUI builder for Parsec. This will allow
Parsec users to easily build GUI's similar to ours or NAM's in a more or
less visual environment. The Parsec people are also working on a visual
programming interface to the Parsec language itself (similar to Visual
Basic or Visual C++).
- Practically speaking, we felt that building our similution
using Parsec would be substantially easier and faster than doing so using
NS. There are several reasons for this:
- Building our simulation using NS would have required us to modify,
augment, and become intimately acquainted w/ the internals of NS (its
implemetation). Even if we just wanted to build a simple test program to
send a simple message from once cache server to another, this would have
been non-trivial using NS. By contrast, Parsec provides a nice level of
abstraction and provides an extremely simple interface to its various
capabilities (message passing, simulation time, message queues, etc). In
fact, after reading the relatively good and concise documentation on
Parsec (which took about 1.5 hrs), we were immediately able to implement
the aforementioned test program in 5 minutes. Thus, Parsec seems to also
be more scalable than NS in the sense of the learning curve as a function
of the number of modules.
- Using Parsec was made easy by its good and concise on-line
documentation. By contrast, we found the on-line NS documentation
available from its home page at Berkeley inadequate for our needs.
Although this documentation explained in detail the various networking
modules available in NS, it said nothing about how one can extend the
simulation language. In addtion, there was no NS workshop available at
the time of our decision.
- Parsec's nice abstractions and ease of use
directly contribute to cleaner, more concise code, which in turn lead to
more maintainable and robust code (I have heard of several studies that
show a strong correlation between code size and the number of bugs in the
code). These are important considerations especially if we plan to make
our code available to the public to use. These factors also help to
maximize our efficiency, which may be critical in helping us to meet our
tight deadlines.
- We felt that an important advantage existed in the fact that the
implementors of Parsec were just a few offices away (Parsec was developed
by Prof. Bagrodia's group at UCLA). We thought that this could be useful
if we had any special feature requests, critical bug reports, or detailed
technical questions (and in fact, this proved very useful since we did
have a minor feature request and had several detailed technical
questions).
- The fact that NS uses oTcl as a the scripting language to "glue" the
various modules together added additional learning overhead since none of
us were particularly familiar with oTcl. In addition, getting our new
modules to work correctly with Tcl could also add additional complications
(and none of us were familar with the Tcl debugger; Parsec programs can be
debugged with any C debugger including gdb and Sun's debugger.)
- From a pragmatic standpoint, since our work on the AWC/CGMP
simulation was also the basis for our class project, we were under severe
time constraints (UCLA is on a 10 week quarter system and we spent the
first 2 weeks of class choosing project groups and ideas. Plus we had to
reserve the last 2-3 days to write our 10+ page report :). Thus, minimal
learning overhead, ease of use, and fast resolution of potential problems
were particularly important to us.
- Although NS is probably more widely used than Parsec/Maisie
(especially in the network research community), Parsec/Maisie has been/is
being used by various companies in industry and universities including
BBN, UKansas, IBM Yorktown Heights, and UCLA. It has been used extensively
here at UCLA for various network simulations including wireless and ATM. Most
notably, it is being used by the GloMo project.
- Finally (yes, finally :), it wouldn't be much work for us to make our
CGMP (and later CRP) modules available to the networking community to use
as Parsec modules (or more accurately, "Parsec entities"). These entities
could be easily incorporated into another Parsec simulation.
I believe we made the right decision...
I have had a very positive experience with Parsec, and I
think it serves our needs well.
Khoi Nguyen and Adam Rosenstein and Nathan Sturtevant
|
