[e2e] Is sanity in NS2?

Detlef Bosau detlef.bosau at web.de
Wed Sep 14 07:59:44 PDT 2005


Jon Crowcroft wrote:
> 
> i dont think i disagree with 98% of what you say...
> 

Encouraging.


> In missive <43282B0D.9010303 at web.de>, Detlef Bosau typed:
> 
>  >>The problem with proprietary code is that I cannot validate it. I cannot
>  >>  read the code. I have to "believe" it.
> 
> you can validate a simulation.
> you dont have to have the code -

Although this is correct in theory, it is quite difficult to do
practically.

The best, and basically the only _real_, validation is to compare
simulation results with reality.

If you can´t do this, e.g. because you don´t have a network which is
large enough or you have no UMTS testbed or whatever, you have to rely
upon simulations.
It´s an excuse. Of course. Most simulations are an excuse. And mostly,
they are a _weak_ excuse. (I got a paper rejected because the reviewer
wanted
to see an implementation, not a simulation. And in commercial business,
no one is interested in simulations. I have seen this myself. When there
is a database system to be sold and this has to work with 1.000 clients
in parallel, there _are_ companies who simply say: You want to sell me
your system?
Go ahead! Make a demonstration with 1.000 clients and then we can
continue the discussion. And I perfectly understand this attitude.)

> 
> 
>  >>I basically don't believe that making thinks more complicated would be =
>  >>more helpful.
> 
> I am not suggesting making it more complex - i am suggesting that
> there is a level of competence that in systems that require
> programming rather than script hacking, is more in evidence.
> 

Working with the NS2 _requires_ programming. When you work with
protocols in the NS2, most of the work is done in the .cc Code.

I don´t know anything about the history of NS2, so I can only guess why
Tcl was ever used here. However, I have a quite old PC who tells me
the story well: When I rebuild the system, even the _link_ run takes
about half an hour. Therefore I guess, Tcl was used to have a means
to plumb NS2 components together without having to compile parts of the
system and toing a link run afterwards.

Today, one could argue that one could drop the whole Tcl/OTcl/TclCl part
of the NS2 and rewrite it totally in C++ or Java.
(Basically, I prefer C++ , but this is a matter of taste.) 

At least, the whole program would becomae much more clear then.
Basically, the NS2 is a framework, a set of components with which you
can model
networks. And basically, it does not really matter whether these
components are glued together in Tcl or in C++. Pure C++ would be clear
and easy to understand.
I guess, Tcl was only used to spare compliation time and link time.
(This is however a guess of mine, perhaps someone could add _knowledge_
here.)

The problem with unbound variables you mentioned is simply a consequence
of this Tcl/C++ interaction which eventually becomes quite cumbersome to
understand.
And simply spoken: It´s not really necessary today.

Howver, we could agree here in that respect that even to write a main.cc
and to run a compiler would deter those guys who simply plumb together
a short Tcl spript by copy´n paste and think that this is "working with
the NS2". Although a main program in C++ would not necessarily
be more complex or longer than one in Tcl.


>  >>In my opinion, the main issue is discipline and proper maintenance.
> 
> I agree (and lloyd made this point too ) - the open source communities
> that are succesful and continuing in quality have moderation.
> 
> what would be nice is if papers submitted using open source, submitted
> the code for audit AS WELL, before the paper could be accepted. (and

I agree here. Altghouh I don´t know how this can be done practically.
It´s an interesting thought to submit a paper double blind, e.g. for
Mobicom,
and to write: I must not tell you my name, but the programs used for
this paper can be found at www.detlef-bosau.de/.....
Perhaps, my provider can offer me a pseudoynm....

The more important problem is, that a reviewer must be willing and able
to _read_ this code. Basically, this would require some competence for
the reviewer as well.

> before the code could be rolled into a distribution) - only if both
> paper and code are ok, is either paper or code accepted.


This is a good idea.

I´m waiting for the first conference to do so.
 
> in the medical world when papers on clinical trials are submitted the
> clinical trial itself (and data) are audited. this is a Good Thing.

In theory. And if done practically, this is also true.

However, there are often "somwhat unfortunate exceptions from the rule"
here.... As I said: It´s somewhat unfortunate.

> 
> the other stuff people do with NS should be kept in the classroom
> imho
> 
> btw, i've given up coding- i find it too painful on my hands.


It may be painful on your hands. However, for me: Do I have an
alternative?

And, you might disagree here as well but I can live with that: Only a
programmer can read programs.

No violinist, no pianist ever stopped playing when he started teaching.
Perhaps, elder singers will not perform in the Opera in public, when
they get older and it´s simply to strenous for a singer at age 83 to
give a public concert. However, they all do not stop playing or stop
singing.
I did not learn Java during my education. How should I ever review a
Java program without ever having written one myself? I couldn´t.
I could make some quotes from some textbooks, but I would not have the
least idea, what Java is all about. When I shall review programs written
in Java, I must _write_ programs in Java. When I shall value programs, I
must _write_ programs.

Would you practice piano playing with a supervisor who always says: "Oh,
when I remember the good old days, where I played the piano myself,
it was, let me think, in the 1930s or so..."? I don´t think so. You
would escape and look for a new teacher.


Detlef

-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937


More information about the end2end-interest mailing list