RE: [ns] improving the ns development

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

On Tue, 7 Aug 2001, Neundorf Alexander wrote:

> > On Tue, 7 Aug 2001, Neundorf Alexander wrote:
> > 
> > > 	One example: the gsm/gprs extension from Richa Jain would be
> > > a very good candidate for ns, or the BlueHoc from IBM,
> > 
> > those are large extensions adding new functionality rather than useful
> > fixes/patches.
> > 
> 	Yes, but is this a problem ?

The ns wireless stuff can be thought of as one enormous patch
(originally from the CMU/Monarch guys), and it's still not that
integrated with the rest of ns. The satellite stuff hangs off that;
ditto for lack of interoperability - mixed topologies, say. Adding
even more large patches increases subtle breakage/reinforces the
status quo. Eventually the codebase atrophies due to its size and the
sheer effort of changing anything successfully; entropy can't be
beaten.

And then you have to start again from scratch.

> > ns is already too large to be easily maintained.
> > 
> 	Well, it's no easy task, but it's doable.

a difficult assertion to prove.


> 	Well, at the moment where somebody is implementing it, he
> will probably check whether the results are meaningful for him,

which doesn't mean that they're right, or that the implementation is
the best way to include such features in ns. It's merely an expedient
way of getting necessary results.


> and if from one day to another the results of other simulations
> from other users change they will probably notice this IMO.

there's a lot that falls in the gaps between the validation
tests.


> > > And I also think most people who *use* ns also more or less know
> > > the code of ns and therefor are not really "clueless".
> > 
> > Well, I use ns, and I'm clueless. Don't ask me about adhoc routing
> > or wireless code, or how classifiers work.
> > 
> 	But you are probably not clueless about the stuff you do :-)

get a second opinion.

> 	And so the people working with wireless stuff are probably
> not clueless in this area.

this doesn't help with integration with other areas or with improving
the overall ns framework.

> 	At least this is wrong for the kde code base, and this is a
> really large one.

It's far easier to play with and test out UIs than it is
obscure simulations. (Not least because everyone has an opinion on
UI, and because changes are _visible_. One reason why nam has
advanced so rapidly, I think.)


> > > 	I don't think ns needs any more features. What it needs is for the
> > > > existing features to work together in a more coherent fashion.
> > > 
> > > 	Well, ns definitely misses support for mobile cellular
> > > systems (gsm, gprs, umts). 
> > 
> > No, that's just buzzword featurism; you can approximate these at a
> > suitable (if very crude) level of abstraction with what's already in
> > ns, and a lot of GSM-like work has already been done with ns.
>
> 	How ?

by setting path delay/link error statistics to useful approximations 
that match those of the allocated channel, setting up a bottleneck
link on an internet path to explore TCP performance etc.

Not that useful for really detailed MAC/physical work, admittedly.

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>