Re: active networking in ns

[Guillermo Rodriguez Garcia <guille@iies.es>]

At 18:13 18/10/99 +0200, you wrote:
>
>> 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

Yes, sorry, it was me. A message bounced and I sent it again (and as a
result it arrived twice to the list :-? )

>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.

I see your point. Also, your idea is very interesting.

>> 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.

I'm "using" the packages for ns2b4 (I'm not actually using them, just basing
my implementation upon them). The ns2b5 version seems to be missing from the
web page.

>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

No, I think that ANAgent is the 'generic' active agent while ANActiveAgent
in ANActive.cc is an example implementation of an active agent. I mean, I
think you are supposed to build your own agents in top of ANAgent, (and
of course write a new packet format) and ANActiveAgent is provided as an
example only (but I might be wrong).

You are right in that there is no "active networking" there in the sense
that there is no code being carried in the active packets. But it isn't
that different, really. In your implementation, you carry a string which
explicitly identifies a Tcl procedure. Here, you can assume that there
is an implicit reference to the code that is to be executed; this implicit
reference is represented by the class type of the active agent.

It's clear that the code loading and caching system is not being simulated
under these approaches (neither yours nor PANAMA's, if I have understood
it well). So in both cases, one should assume that the code has already
been distributed to all nodes and so they are ready to process the active
packets they receive.

So I think there are two key differences between your solution and
PANAMA's.

The first difference is about how active packets are routed: either
end-to-end default routing or (active)hop-to-(active)hop default
routing. If static routing is used, both solutions should work
exactly the same way. But your solution won't work with dynamic
routing, while PANAMA's will. So I think theirs is more generic
in this respect; but it also has the a potential drawback in
that ns internals need to be modified, which is not needed
with your approach.

The second difference is about how active packets are evaluated.
Your solution sends a string identifying the Tcl procedure to be
run at each node, which is probably closer to the real behaviour
of active packets. PANAMA's approach involves deriving new classes
from their ANAgent and install them at each active node, thus
assuming that code belonging to the active protocol has already
been distributed and is available at nodes. Here, I think your
solution is better than PANAMA's in the sense that it offers
a closer insight of what really happens in active networks.

Anyway, both should give the same results for simulating and
evaluating new protocols (assuming static routing again).

There is one thing that is not entirely clear for me yet. With
your solution, if you need to have custom fields in the active
packet header, how/where do yo carry them? In other words, how
do you store state information associated with each active
packet? Just imagine a simple, stupid active packets that
records routes from source to destination. Implementation
should be straightforward with PANAMA's approach because
you have a new packet format for each new active protocol,
so you can just carry a list of node addresses and append
each node that you visit as you travel the network. How 
would you do this with your approach?

>> 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 would like to have an eye at it when it is ready anway,
even when I won't probably be able to use it for this project.

>> 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?

It shouldn't have any impact on protocol behaviour, because in a true
active network you shouldn't be able to control where the active nodes
are located exactly. Also, if the packet is evaluated in an active node
which you hadn't detected before, when it leaves that node it will be
sent to the one expected, so there is makes no difference with regards
to routing.

>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?

I'd say it's the latter; it reflects the inability of protocol developers
to know where active nodes will be found in a real network.

>> 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...

Yes :-)

Regards,
G.
--
Guillermo Rodriguez Garcia
<guille@iies.es>