Subject: [manet] Route convergence time in proactive protocols

From: "Breno Jacinto" <[email-masked]>
Date: Tue, 25 Nov 2008 16:08:06 -0300

Hello,

   I'm researching on ad hoc networking protocols, specially using
proactive approaches such as OLSR. The basic premise, as you may know,
is that nodes are constantly generating traffic to update routes to
other nodes in the network, in such a way that every node on the
network, is aware of other nodes even if they are several hops away.
My question is, since my experiments are restricted to a few nodes
(less than ten), I'm not sure if, given some scale, how long would it
take for every node to see each other and be able to communicate. Has
anyone here had such an experience?

   I'm aware that there are some practical lower layer limitations on
performance, as previous research have shown (LUNAR, ad hoc horizon
etc.). But, still my doubt remains if, for example, in OLSR, every
node is really able to see a node that is five or more hops away from
it, and vice-versa.

   I hope this is the right list for this type of question, if it is
not, please apologize.

best regards,

-- 
-- 
:: Breno Jacinto ::
:: breno - at - gprt.ufpe.br ::
:: FingerPrint ::
   2F15 8A61 F566 E442 8581
   E3C0 EFF4 E202 74B7 7484
:: Persistir no difícil é a única maneira de torná-lo fácil algum dia.  ::
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 26 Nov 2008 09:57:19 -0000

> But, still my doubt remains if, for example, in OLSR, every

There's no problem seeing a node five hops away, unless
packet loss rates are excessively high, in which case you
would have problems using such a route even if you found it.
(Finding can tolerate a significantly higher error rate than
most uses can.)

A trickier question is whether your information about
distant links is sufficiently up to date, which depends
on the rate of change of your network (whether due to
mobility or anything else) and how frequently you send
TC messages. Actually that's not quite all, if you read
up on fisheye routing, and fuzzy/hazy sighted link state
routing, they depend on that you don't need quite such up
to date information on more remote nodes/links (although
that in turn depends on various factors such as the amount
of redundancy in your network). These protocols then
actually reduce the amount of long distance flooding.
Combination of these concepts with OLSR has been
demonstrated, although there's a small technical nit over
validity time advertisement. This is fixed in OLSRv2,
which explicitly describes the concept. But even without
using the fisheye concept, the principle that long distance
information can often afford to be slightly less current
still applies.

Finally note that to get long distance routes (but here
five hops is not excessive) you need more nodes, and there
comes a point at which that gets too large (although
techniques such as fisheye and others can help).

(As for whether this is the right list, I think the answer
is, in moderation. The real work in this area is in OLSRv2,
and the purpose here is to get that out, plus of course the
other protocols, DYMO, SMF in their areas. So considering
how well those work - and for the most part OLSR and OLSRv2
behave similarly, although obviously with some improvements
in the latter - is on topic. But the literature, of which
there's quite a lot, will cover more than discussion here.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Breno Jacinto" <[email-masked]>
Date: Thu, 27 Nov 2008 13:48:11 -0300

Hello Christoper,

    Thanks for the answer. I belive you got the real point here:

> information can often afford to be slightly less current

   So, let me explain exactly what I'm into: how reliable is a "ping
<some IP>", which may return an ICMP unreachable message, which may
mean that:

1) That IP is not really used on any of the nodes in the network
(which may be true if the routes are really consistent)

2) The pinging node is not with the most up-to-date information on the
topology, which will get an ICMP unreachable message, when in fact
there is a node in the network using IP <some IP>. As you said, due to
mobility or any other factor, this outdated topology data (especially
for distant nodes) may happen, leading to a false reply.

    Finally, the real use of this is simply that, if we could trust
those ping replies, we could be pretty sure that that <some IP> is
available for other nodes to use in the network. This way, we could
minimize all the overhead generated by duplicate address detection and
correction which are employed in many mechanisms (in this case, my
interest would be to assure the <some IP> is not used prior to an
assignment of the new node joining the network).

   A mechanisms that gets close to this is PAA (Pro-Active Auto-config
- http://www.olsr.org/docs/report_html/node179.html), but it still
does flooding to assure the IP is not really being used anywhere in
the network.

> there's quite a lot, will cover more than discussion here.)

    OK, thanks for the hint :). The reason for posting was hoping that
someone would have a practical experience on moderate to large ad hoc
networks, using any protocol.

best regards,