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: Tao Lin <[email-masked]>
Date: Tue, 6 Aug 2002 19:30:14 -0400

hi, Richard,

I got the ns2 simulation code from both of OLSR and TBRPF.

The source code of OLSR ns2 code (the packet size bug fixed version) uses
similar way to measure the control overhead as other existing protocols, e.g.
AODV, DSR. They all use the cmu_trace.cc to generate trace files with entries
of packet sizes for all control packets. Therefore we can use a analysis
script to count the control overhead in the output trace file.

In the source code of TBRPF, I can't figure out how can we count the packet 
sizes. Can you tell me how do you measure that in TBRPF so that I can do some
comparisons? Thank you very much!

 Tao Lin
 Virginia Tech

>===== Original Message From [email-masked] =====
>Thomas,
>
>> Dear Richard,
>>
>> I just want to correct some of your assesments.
>>
>> On Mon, 5 Aug 2002 [email-masked] wrote:
>>
>> <SNIP>
>>
>> > 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
>>
>> 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.
>>
>> >   - 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)
>>
>> 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.
>
>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."
>
>>
>> <SNIP>
>>
>> > 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.
>> >
>>
>> 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.
>
>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
>
>
>
>>
>> --
>>
>> -------------------------------------------
>>   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
>> -------------------------------------------
>>
>>
>