Subject: Re: [manet] OLSR optimizations

From: [email-masked]
Date: Wed, 07 Aug 2002 10:44:28 -0700

Hi Tao,

We generate a trace file in the same way as AODV.
The packet type for TBRPF control packets is PT_MESSAGE
(this avoided the need to define a new packet type).

I will send you our tcl script file in a separate email.
Let's take further discussion of this topic off the
manet list (as previously requested by Joe Macker).

Regards,
Richard

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

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

---

From: [email-masked]
Date: Wed, 07 Aug 2002 10:44:28 -0700

Hi Tao,

Regards,
Richard

---

From: Tao Lin <[email-masked]>
Date: Tue, 6 Aug 2002 19:30:14 -0400

hi, Richard,

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