Re: [Roll] Trickle clarification: (in)consistency

["Pascal Thubert (pthubert)" <pthubert at cisco.com>]

Hi Mathilde;

I agree with Jonathan that we want to avoid redundancy.

The rank of metric that a node advertises is an information about self
that cannot be inferred from the neighbors so it is *not* redundant. If
a number of nodes go down at the same time and one does not advertise,
then that node will look better and will attract the traffic. It will
also attract the neighbors that went down and that will be tempted to
reattach to that apparent survivor.

The information in the DIO that relates to the DAG configuration will be
centralized in an option that IS redundant. We could add text that a
node that see C of it MAY filter it out from its DIO.

Finally the new sequence is redundant. I proposed to use it to limit the
density of routers using trickle. When you hear C router advertising a
new sequence you are entitled to stop being a router for that sequence
(stop trickle timer). The trickle timer would then be restarted upon a
DIS to serve orphans, and upon a next sequence to redistribute the load.

Pascal

>-----Original Message-----
>From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
Jonathan Hui
>Sent: vendredi 20 novembre 2009 16:41
>To: Mathilde Durvy (mdurvy)
>Cc: roll at ietf.org
>Subject: Re: [Roll] Trickle clarification: (in)consistency
>
>
>Hi Mathilde,
>
>On Nov 19, 2009, at 9:24 AM, Mathilde Durvy (mdurvy) wrote:
>
>>> - when do we increment C?
>>
>> The node MAY increment C when it hears another DIO.
>>
>> I think the spec says that a node MAY increment C each time it hears
a
>> "consistent DIO for this DAG from a DAG parent". What fields are
>> included in the consistency check? If only generic DAG information
are
>> checked you might want to look at DIO from non-DAG parents, no?
>
>You're right, this text in the draft is incorrect.  There's an
>important distinction to make here.  We want to quickly send DIO
>transmissions (reset the Trickle timer) whenever *inconsistencies* are
>detected.  But you want to suppress DIO transmissions (increment C)
>whenever *redundancies* are detected.  While you can detect
>inconsistencies by listening to your DAG parent(s), redundancies will
>probably come from your siblings/cousins.
>
>We are looking to update the text around incrementing C and make what
>constitutes a redundancy more precise.
>
>--
>Jonathan Hui
>
>_______________________________________________
>Roll mailing list
>Roll at ietf.org
>https://www.ietf.org/mailman/listinfo/roll