improving regression tests of ns-3

hi,

While trying to add a bunch of new tests to the regression
testsuite in
ns-3, it occured to me that we could add a stupid
NetDevice/Channel
implementation to provide cross-node connectivity and help
testing of
the higher-layers. This would allow us to avoid making the
internet-node/udp-socket.cc test code depend on
PointToPointNetDevice...

So, I would like to add to src/node/ (the main reason to add
them to
src/node and not to src/devices/simple/ is that I want to
re-use them
from applications/ and internet-node/):

  - simple-net-device.h/cc
  - simple-channel.h/cc

Both would work together and provide a multipoint broadcast
medium
without any kind of MAC/PHY/queuing models and no state
managament. Just
packet forwarding. Actually, 'Forwarding' might be a better
prefix:
ForwardingNetDevice, and ForwardingChannel.

Since this stuff is pretty straightforward, in the absence
of comments,
I will proceed with this tomorrow and push the additional
regression
tests to ns-3-dev.

Mathieu

On 19/03/2008, Mathieu Lacage <mathieu.lacagesophia.inria.fr> wrote:
>
> hi,
>
> While trying to add a bunch of new tests to the
regression testsuite in
> ns-3, it occured to me that we could add a stupid
NetDevice/Channel
> implementation to provide cross-node connectivity and
help testing of
> the higher-layers. This would allow us to avoid making
the
> internet-node/udp-socket.cc test code depend on
PointToPointNetDevice...
>
> So, I would like to add to src/node/ (the main reason
to add them to
> src/node and not to src/devices/simple/ is that I want
to re-use them
> from applications/ and internet-node/):
>
>   - simple-net-device.h/cc
>   - simple-channel.h/cc
>
> Both would work together and provide a multipoint
broadcast medium
> without any kind of MAC/PHY/queuing models and no state
managament. Just
> packet forwarding. Actually, 'Forwarding' might be a
better prefix:
> ForwardingNetDevice, and ForwardingChannel.


In src/internet-node/udp-socket.cc you will find already
some unit tests of
higher layers, UDP sockets in this case.  I implemented it
using
PointToPointNetDevices connecting some nodes.  I think it
works well, and to
be honest I don't completely understand why a new special
netdevice is
needed just for unit testing.  I mean, PointToPointNetDevice
is
deterministic, so it should be more than enough for any kind
of unit
testing...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." --
Frank Herbert

On Wed, 2008-03-19 at 23:39 +0000, Gustavo Carneiro wrote:

> 
> In src/internet-node/udp-socket.cc you will find
already some unit
> tests of higher layers, UDP sockets in this case.  I
implemented it
> using PointToPointNetDevices connecting some nodes.  I
think it works

yes, I know.

>  well, and to be honest I don't completely understand
why a new
> special netdevice is needed just for unit testing.  I
mean,
> PointToPointNetDevice is deterministic, so it should be
more than
> enough for any kind of unit testing...

the problem is that the module 'internet-node' is not
supposed to depend
on the 'point-to-point' module. Furthermore, for the sake of
writing
tests, I would like to test only what I am interested in,
not some other
random piece of code like PointToPointNetDevice. i.e., I
would like to
isolate the different components of the system to avoid
testing
unrelated pieces when I really want to test UdpSocket.

Mathieu

On 20/03/2008, Mathieu Lacage <mathieu.lacagesophia.inria.fr> wrote:
>
>
> On Wed, 2008-03-19 at 23:39 +0000, Gustavo Carneiro
wrote:
>
> >
> > In src/internet-node/udp-socket.cc you will find
already some unit
> > tests of higher layers, UDP sockets in this case. 
I implemented it
> > using PointToPointNetDevices connecting some
nodes.  I think it works
>
>
> yes, I know.
>
>
> >  well, and to be honest I don't completely
understand why a new
> > special netdevice is needed just for unit testing.
 I mean,
> > PointToPointNetDevice is deterministic, so it
should be more than
> > enough for any kind of unit testing...
>
>
> the problem is that the module 'internet-node' is not
supposed to depend
> on the 'point-to-point' module. Furthermore, for the
sake of writing
> tests, I would like to test only what I am interested
in, not some other
> random piece of code like PointToPointNetDevice. i.e.,
I would like to
> isolate the different components of the system to avoid
testing
> unrelated pieces when I really want to test UdpSocket.


Well, you'll still be testing SimpleNetDevice anyway... you
can't run away
from testing other things.  I'm not sure SimpleNetDevice
will be that much
simpler than PointToPointNetDevice.  But if you really want
it, well, it's
your work.. 

You make a good point about internet-node depending on
point-to-point.  I am
to blame, but I hate that.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." --
Frank Herbert

On Thu, 2008-03-20 at 00:40 +0000, Gustavo Carneiro wrote:

> You make a good point about internet-node depending on
point-to-point.
> I am to blame, but I hate that.

you hate being blamable ? 

I don't like it either, but, well, it does happen pretty
regularly 

Mathieu

On Thu, 2008-03-20 at 06:17 -0700, Tom Henderson wrote:
> >> the problem is that the module 'internet-node'
is not supposed to depend
> >> on the 'point-to-point' module. Furthermore,
for the sake of writing
> >> tests, I would like to test only what I am
interested in, not some other
> >> random piece of code like
PointToPointNetDevice. i.e., I would like to
> >> isolate the different components of the system
to avoid testing
> >> unrelated pieces when I really want to test
UdpSocket.
> > 
> 
> 
> I think that what you suggest is reasonable (a simple
net device usable 
> across all modules, located in src/node) but a more
useful TestNetDevice 
> or SimpleNetDevice might also include other modeling
capabilities.  I 

Ok. Do you have a preference for the name ?

What you describe below (michele's delaybox) looks, however,
pretty
generally useful. 

> can envision, for transport testing, that one would
want to be able to 
> model also delay (and jitter) and dropped packets,
independently 
> settable in forward and reverse directions.  These
could be based on 
> random variables and still keep the device/channel
otherwise stateless.

I have something for the transmission delay in
src/devices/wifi/propagation-delay-model.h

> 
> I would recommend to look at Michele Weigle's DelayBox
for ns-2:
> http://dirt.cs.unc.e
du/delaybox/

Looks cool. So, this puts together a propagation delay
model, an error
model and a flow classifier ?

What is missing from our current codebase would be a flow
classifier
then. Maybe something like this:

class FlowClassifier
{
public:
  virtual uint32_t Classify (Ptr<const Packet> packet)
= 0;
};

class TcpFlowClassifier : public FlowClassifier
{
public:
  // methods to configure classification.
};

Another API would be to make the FlowClassifier::Classify
method tag the
input packet with a 'flowid' tag instead of returning an
explicit
uint32_t. Or it could do both.

And, then, what you would need is something which would take
as input a
classified packet, and apply some delay+error model in a
queue.

regards,
Mathieu