Re: active networking in ns

[Lidia Yamamoto <yamamoto@run.montefiore.ulg.ac.be>]

Hi Guillermo,

> first because I need to simulate large, complex networks and so I wanted
> to remove everything not needed for my own protocol. I mean, my problem

Yes, I understood that after I sent my first message (somebody changed an "A"
into "a", causing the thread to split, and since I don't read all the messages I
had to do some search to find your initial message). So I don't think my simple
implementation suits your case, since I sacrified performance for generality.

Anyway, what I tried to point out was that it is possible to simulate AN in ns
without having to modify the classifier, by using an approach similar to tunnels,
instead of an approach based on "router alert". This is simple to do but less
efficient.

> was NOT that the pkg was not generic enought, but rather that I wanted
> to keep things as simple as possible (to keep the overhead low).

This looks interesting. Which version of the PANAMA package are you using? I only
tested the packages for ns2b4; I saw that there is a ns2b5 version now, but I was
unable to download it.

In the version I have (ANpkg_ns2b4), it allows a node to intercept a packet on
its way to the destination, sending it to a local agent. In principle, I see no
active networking in this, it looks more like "router alert". So it is really
generic. However, several fields and packet types are defined (hdr_an in
ANAgent.h). I think this is contrary to the AN idea of having packets carry
instructions (code) instead of pre-defined fields with pre-defined meaning.
Besides that, it seems that things like "ip->dst_ = group_;" (process_ANpkt,
ANActive.cc) are really specific to multicast. Additionally, it seems that anyway
ANpkg_ns2b4 is not generic enough because even PANAMA's  own AN_rmpkgns2-4
(reliable multicast) needs to modify it by introducing even more packet types
with pre-defined meaning (NACK and REPAIR).

> The only problem is that I need to complete the simulation stage
> before the beginning of november, when I will be starting the
> implementation of my protocol under MIT's ants toolkit.

I understand it. Unfortunately I don't think it is realistic for me to have an
optimised implementation before this date, since the implementation I have now is
not really intended for thousands of nodes.

> I don't see why: after all, if you want to do full-custom routing,
> you can just change the destination node in each active agent,
> so instead of relying in IP routing from src to dst you will
> be explictly specifying the route in a hop-by-hop basis.

Yes, you are right, sorry for the noise. Such a "router alert" solution actually
only depends on an extra IP option, which will hopefully be ignored by routers
that don't know what it means.  However, in the hop-by-hop routing, we need to be
careful with the fact that our packets might be evaluated in other intermediate
nodes on the way to the next hop (which we might not have detected before). What
is the impact of this? Maybe it depends on the application? Or is it just a
matter of carefully designing the customized routing protocol in order to take
this situation into account?

> If you don't handle routing in your active agents, then IP routing
> is used as default, which is not a bad thing, given the fact that

I agree.

> But what is the difference? You also rely on IP routing to get from
> one active agent to the next one...

I don't rely on end-to-end (AN application to AN application) IP routing nor on a
router alert option. I look at IP as a link layer to transport active packets
from one AN hop to the next one. That makes things simple, but as you pointed out
before, this is not the only way towards a generic solution, nor the most
efficient. PANAMA offers a "best-effort NodeOS" that is able to intercept active
packets and send them to an initially empty EE. It is up to us to derive an EE
from ANAgent (actually I could certainly run my simple EE on top of PANAMA once
the multicast dependencies are eliminated). It seems there is still quite some
work to be done...

Lidia.