Subject: [manet] OLSR optimizations

From: John Novatnack <[email-masked]>
Date: Mon, 05 Aug 2002 11:10:54 -0400

Hello  All,
   As you may or may not know, the most recent implementation of OLSR 
for the NS-2 simulator is from draft version 3 and for Ns-2 version 
ns-2.1b7a.  I have ported this version to the newest version of Ns-2, 
and added a routing layer queue for buffering packets with no route.  My 
question is this, are there any other significant features of OLSR that 
have been added since draft 3, that should be implemented in ns-2 in 
order to create an accurate representation of the routing algorithm?  I 
am most interested in comparing proactive vs reactive protocols, and do 
no wish an incomplete implementation to tarnish the results.

Thanks in advance,
-john

-- 
John Novatnack
[email-masked]

ITCSL Laboratories <http://plan.mcs.drexel.edu/>

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Mon, 05 Aug 2002 17:01:33 -0700

> no wish an incomplete implementation to tarnish the results.

Hi John, 

I brought up this issue at the meeting in Japan.
I list below what I think are the main changes to OLSR
since version 3.  Some of these changes (e.g., multiple interfaces)
are not important for a basic simulation with a single interface and
no redundancy, but some of the changes (marked *) could potentially affect 
performance significantly even for a basic simulation.  

Version 5: 
  * Introduction of LOST_LINK status (helps to recover more quickly from link failures)
  * Hysteresis for neighbor sensing
  - Multiple interfaces 

Version 6:
  * Advanced fast re-routing mechanism 
  * Introduction of REFRESH_INTERVAL (allows each neighbor to be included in a HELLO
    less frequently than HELLO_INTERVAL)
  - Introduction of MPR_COVERAGE (allows option of redundant MPRs)

Version 7:
  - Relay willingness
  - Optional redundant link set in TC messages

I am hoping to obtain more recent ns-2 code for OLSR.
Joe Macker mentioned earlier this year that he had such code,
so maybe he can help us.

Also keep in mind that OLSR had a bug affecting packet size (previously mentioned
on the list) that does not appear to have been fixed in the ns-2 code available
from the OLSR site.

On the other hand, since you are most interested in comparing proactive to reactive routing,
you can obtain up-to-date ns-2 code for TBRPF at 
http://www.erg.sri.com/projects/tbrpf/

In our simulations, TBRPF outperformed OLSR in all scenarios, so maybe this 
would suit your needs better anyway.

Regards,
Richard

---

From: [email-masked]
Date: Mon, 05 Aug 2002 17:01:33 -0700

Hi John, 

Version 5: 

Version 6:

Version 7:
  - Relay willingness

Regards,
Richard

---

From: [email-masked]
Date: Tue, 6 Aug 2002 13:05:31 +0200 (CEST)

Dear Richard,

I just want to correct some of your assesments.

On Mon, 5 Aug 2002 [email-masked] wrote:

<SNIP>
 
>   * Hysteresis for neighbor sensing

The impact of the above in ns2-simulations are questionable. In real-world
scenarios with real 802.11 cards etc, hysteresis makes a difference.
However the difference has not been reproduced to the same extend in ns2.
Personally, I think it is the mac/physical model of ns2 that is too
limited to permit this.

>     less frequently than HELLO_INTERVAL)

REFRESH_INTERVAL and HELLO_INTERVAL, as described in the later drafts, is
not intended to let a node be included less frequently. Rather, it is
intended to support the hysteresis described above.

<SNIP>
 
> In our simulations, TBRPF outperformed OLSR in all scenarios, so maybe
> this would suit your needs better anyway.
> 

I hate to mention this, much less make it a topic for discussion, but I
have been unable to reproduce the results that your simulations have
showed for OLSR.

-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: [email-masked]
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------

---

From: [email-masked]
Date: Tue, 6 Aug 2002 13:05:31 +0200 (CEST)

Dear Richard,

<SNIP>

<SNIP>

--

---

From: [email-masked]
Date: Tue, 06 Aug 2002 12:28:33 -0700

Thomas,

> intended to support the hysteresis described above.

I was not trying to state your intention. I was simply stating a fact which 
follows from the following paragraph in the OLSR draft:

   "The list of neighbor interfaces in a HELLO message can be partial
   (e.g. due to message size limitations, imposed by the network), the
   rule being the following: for each interface a neighbor interface is
   heard on, its address is cited with corresponding interface id at
   least once within a predetermined refreshing period, REFRESH_INTER-
   VAL. To keep track of fast connectivity change a HELLO message must
   be sent at least every HELLO_INTERVAL period, smaller than or equal
   to REFRESH_INTERVAL."

> have been unable to reproduce the results that your simulations have

I explained in a previous email why our results might be different, e.g., 
differences in the traffic model, etc.  I tried to work with you to determine 
the reason for the differences (I sent you my models and asked you to send me 
your models), but you did not cooperate.  In your email dated 3/8/02, you said 
"I suspect serious problems with your control overhead measures."  But we verified 
that we counted control traffic using exactly the same method that you suggested.

In any case, we compared TBRPF to OLSR using valid traffic/network 
models (even if our models differed from yours) and using the ns-2 code for
OLSR from the INRIA website.  We have no reason to suspect any problems with
our results.   

Regards,
Richard

---

From: [email-masked]
Date: Tue, 06 Aug 2002 12:28:33 -0700

Thomas,

Regards,
Richard

---

From: [email-masked]
Date: Tue, 6 Aug 2002 22:03:52 +0200 (CEST)

Dear Richard,

<SNIP>

<SNIP>

I was just trying to clarify/state our intentions, to prevent any
confusion from arrising :)

<SNIP>
 
> OLSR from the INRIA website.  We have no reason to suspect any problems with

I am not trying to discredit your work in any ways. I just observe that
basically we do agree that simulation results strongly depend on the
scenarios (traffic, movement etc), and as such need to be seen in a
context, right?

--

---

From: [email-masked]
Date: Tue, 6 Aug 2002 22:03:52 +0200 (CEST)

Dear Richard,

<SNIP>

<SNIP>

<SNIP>

--