Re: [Roll] Revisiting the Trickle Algorithm

[Omprakash Gnawali <[e-mail]>]

On Mon, Jan 19, 2015 at 5:35 PM, Badis Djamaa <[e-mail]> wrote:
> Thank you Gnawali for your comments,
>
>
>
>>Could you discuss the tradeoffs due to the proposed modification? Are
>>there some scenarios that will be worse off due to the changes?
>
>
>
> Figure1, page 2 of the document, shows the scheme in its best-case (lossless
> networks). From that Figure, we can see a side-effect of the proposed scheme
> which can add an extra cost in lossy-networks.
>
>
>
> Figure 4 in page 4, clearly shows this side-effect in lossy networks. But
> results in Figure 5 ( network with 90% physical loss rate) shows that the
> extra cost only affects a few following intervals and disappears later. Also
> Figure 5 shows that this additional cost does not affect trickle
> scalability.
>
>
>
> When generating heavy inconsistencies (periodically injecting new packets),
> testbed results depicted in third row of graphs in Figure 6, page 4, shows a
> bigger additional cost because of heavy inconsistent traffic being
> generated.
>
>
>
>>Did you consider minor variations to your scheme - e.g., rather than
>>just the first interval starting at 0, how about the first n intervals
>>starting at 0 rather than I/2?
>
>
>
> Because of the side-effect depicted in Figure 4, the additional cost
> increases if we go for n intervals. Generally speaking, Trickle's
> scalability might remain logarithmic, because the extra cost only depends on
> losses. However, the extra cost is noticeable under heavy inconsistent
> traffic and wastes energy.
>
>
>
> Note however, that we made a small variation to the scheme by letting a node
> that transmitted in an Imin interval to start listening immediately (put
> c=0). Preliminary results look promising and show that the side-effect can
> be addressed.
>
>
>
> More results are being analysed to see whether other side-effects can
> emerge.


Look forward to this. Could you also post your code so others can do
experiments on different testbeds to verify the results once you have
converged on a design that addresses the side effects. For example, I
can try to have a student do this as a short project in TinyOS.

If the side effects remain, this will be a question of tradeoff in
which case it is better to have this as a commentary in the RFC rather
than replace it.

It will also be helpful to do a survey of what type of intervals are
being used by the community so we know how big a problem this is.

- om_p