[e2e] Is sanity in NS2?

[Detlef Bosau]

Roland Bless wrote:
> 
> Hi,
> 
> Erik Nordström wrote:
> > I totally agree with the statement above. Comparison to reality is the
> > only way to do validation.
> 
> Yes, that's why we ported a real FreeBSD TCP/IP stack into the OMNeT++
> simulator. And guess what: it works very well.

I believe that.

Let´s look what you have now: You hava an OMNET++ simulator with a BSD
stack.
And hopefully, you get a paper from that, good luck!

However, you replaced one simulation by another. Did you by chance read
my reply on George´s post at the end of last week?
IIRC, I´ve written there, that´s no problem to implement TCP into a
simulator. And btw: I don´t want to discuss whether Linux is reality or
BSD (of course, BSD is considered the reference implementation), I
personally have great respects for _standards_. So, a TCP implementation
should always be done
RFC conformant. 

BTW: IIRC, a great deal of the NS2 implementation of TCP was done by
Sally herself. So, the person who wrote the standards and the person
who proposed TCP/Reno and the person who wrote the code were identical.
That´s great! Why did you write a new implementation?
And this is the normal situation. When I worked with TCP/Snnop, I
compared Hari Balakrishnan´s code for BSD and the NS2 more or less line
by line.
And believe me: Despite the parts where the NS2 and BSD are that
different that different coding is _required_, I think the same problem
arises
in OMNET++, the code is identical. Great!

However, my point was not to discuss TCP implementations. This is
implementation work. I´m interested in the behaviour of wireless
networks.
So, in NS2 terminology: Forget about the NS2 except one only
class/source file: delay.h and delay.cc. Anything else I´m willing to
buy,
_this_ one, I _don´t_ . And that´s the only justification to discuss
this here, because this list is not concerned with implementation
details of network simulators. However, it´s concerned with
architectural issues in TCP, and therefore the question whether a
wireless
link raises architectural issues by it´s nature is stronly on topic. 

So, the discussion is: How do we simulate a wireless link? And the only
way to validate a model for that is to compare a model with reality.

(Advantages and disadvantages of simulators)

Some few weeks ago, I thought about whether delay spreading could
alleviate a delay spike or not. Result: It can.
So, I needed a "simulator". O.k. The C++ program was about 100 lines
long. 

Of course, they are situations where the whole overhead of a simulator
is not necessary and I can do the implementation work myself.
However, this raises another question we talked about last week: Who
will ever believe me? Jon argued, that first the code should
be made available, then we may publish the papers. From this point of
view, the ns2 is basically a commonly accepted and commonly used
simulator which is pretty well known to the vast majority of researchers
in this area. Even more, you will find that a lot of source code
was contributed by the authors of the original papers and PhD theses.
This is one of the particular strength of he ns2.
 
> 
> Hmm, I think that it is still necessary to do simulations, especially
> if you want to analyze scalability issues in scenarios with several
> thousand nodes (which I use in OMNeT++).
> 
> Validation of the implemented protocols is however important and
> the hard part of it.

What do you want to validate here? Do you want to validate that the
protocols are logically correct? This is one point. Admittedly,
I don´t know whether a network simulator is the right tool for this or
whether you would better use tools for temporal logic or something like
that.

If you are interested in the behaviour of TCP in wireless networks, how
bursty the traffic will be, how often delay spikes will happen, my
primary
focus is the link model and the delay model. And I would be lucky to
talk about that to colleagues. Perhaps, there is a particular mailing
list
dealing with this issue, I would appreciate any hint. Also, I appreciate
some offlist discussions here because it´s not the core interest of this
mailing linst.

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