[net2-wg] problem with the timer that controls routing beacon rate in CtpRoutingEngineP.nc

[Philip Levis]

On Mar 18, 2008, at 7:50 PM, Omprakash Gnawali wrote:

> On Tue, Mar 18, 2008 at 4:25 PM, Philip Levis <pal at cs.stanford.edu>  
> wrote:
>>
>> On Tue, 2008-03-18 at 14:29 -0800, Omprakash Gnawali wrote:
>>>>> 2. Triggered route updates using the same timer as Trickle  
>>>>> timer. We
>>>>> thought we would be able to fix this by calling resetInterval()
>>>>> instead of starting the timer when we need to generate on-demand
>>>>> beacons. This will ensure that there is only one way to change the
>>>>> Timer. Unfortunately, this will not work - we want to control  
>>>>> how long
>>>>> to wait until we send a beacon in case of on-demand beacons  
>>>>> depending
>>>>> on the situation (trigger update vs trigger immediate update), not
>>>>> possible using a single resetInterval() call.
>>>>
>>>>  Why are there two different cases? What is the difference?  
>>>> IIRC, we were
>>>>  originally trying to distinguish beacons that should send soon and
>>>>  beacons that should send NOW. But in the case of trickle, we  
>>>> can just
>>>>  reduce this to beacons that should send NOW and take advantage  
>>>> of the
>>>>  exponential decay. So we send a few extra packets. Let's  
>>>> simplify it.
>>>
>>> Are you saying that reset should always trigger an immediate beacon?
>>> Right now we set the timer to fire at min interval upon reset.
>>
>>  You should never send an *immediate beacon.* IIRC, even the  
>> "immediate"
>>  beacon is a 32ms timer. So the trickle interval tau_l should be very
>>  small...
>
>
> If tau_l is 32ms, then we will have the next beacon at 64ms, 128ms,
> 256ms, 512ms, 1s - it seems like a lot of unnecessary beacons. To
> prevent this, my approach would be to reset interval to taul_l = 1s
> and specify the first fire time to be 32ms, and when the timer fires
> at 32ms, we look at the value of interval and decide to fire at 1s,
> and we double it, then fire at 2s, etc.
>

Don't forget, the beacon is due to there being a routing  
inconsistency. One of the points in trickle is that the scaling  
inherently leads to a little bit of redundancy. I'm leery of changing  
the algorithm based on a perceived cost, rather than a measured one.  
Let's see what happens to the beacon counts?

Phil