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

[Omprakash Gnawali]

On Tue, Mar 18, 2008 at 8:44 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
>
>  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?

There are three firing patterns - Trickle, trigger (64ms) and
triggerImmediate (4ms). I don't understand how we can accommodate
these three patterns by just resetting unless we are willing to set
tau_l to 4ms. But setting tau_l to 4ms would be an overkill if it is
parent change that triggers a beacon. Or we change triggerImmediate to
trigger so that we can have a more reasonable tau_l of 64ms.

- om_p