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

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 19 Nov 2009 15:57:47 +0100

Hi all,
 
- when the DAG is considered inconsistent, I think we do not double I
when I fires. Correct?
- when do we increment C? 
- most importantly: how does a node know it is in consistent mode?
 
Best,
Julien

---

From: Philip Levis <[email-masked]>
Date: Thu, 19 Nov 2009 07:59:48 -0800

On Nov 19, 2009, at 6:57 AM, Julien Abeille (jabeille) wrote:

> Hi all,
>
> - when the DAG is considered inconsistent, I think we do not double  
> I when I fires. Correct?

When the node detects that there's an inconsistency (or another issue  
that requires routing updates), the node resets I to I_min and starts  
a new interval. You always double I when it fires.

> - when do we increment C?

The node MAY increment C when it hears another DIO.

> - most importantly: how does a node know it is in consistent mode?

When it doesn't detect any inconsistencies. :)

Phil

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 19 Nov 2009 18:24:50 +0100

Hi Phil,  

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?

Best,
Mathilde
_______________________________________________

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 20 Nov 2009 07:41:19 -0800

Hi Mathilde,

> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Nov 2009 20:11:54 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
>Sent: vendredi 20 novembre 2009 16:41
>To: Mathilde Durvy (mdurvy)
>Cc: [email-masked]
>Subject: Re: [Roll] Trickle clarification: (in)consistency
>
>
>Hi Mathilde,
>
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Sun, 22 Nov 2009 22:55:17 +0100

Hi Pascal,

Not sure I understand your explanation. In a DIO there are informations
that are global to the DAG and some that are node specific. We use
trickle because we consider DIO sending a consitency problem, hence we
focus on the global information. They come both from parents and childs,
so I would also increment C when hearing from a child. Am I missing
something?

Julien

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: vendredi 20 novembre 2009 20:12
> To: Jonathan Hui; Mathilde Durvy (mdurvy)
> Cc: [email-masked]
> 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
> 
> >> I think the spec says that a node MAY increment C each 
> time it hears
> a

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Nov 2009 08:54:50 +0100

Hi Julien

Seems to me that so far we are saying the same thing.

We'll be concentrating the DAG information in one option. That option
should be consistent in an iteration. It should thus be subject to
elision if it is redundant with C messages already heard during the
trickle period. Other fields in the DIO might not be redundant though.
My main concern is the routing information. My Rank is not my neighbor's
Rank.

Pascal

>From: Julien Abeille (jabeille)
>Sent: dimanche 22 novembre 2009 22:55
>To: Pascal Thubert (pthubert); Jonathan Hui; Mathilde Durvy (mdurvy)
>Cc: [email-masked]
>Subject: RE: [Roll] Trickle clarification: (in)consistency
>
>Hi Pascal,
>
that are global to the DAG and
>some that are node specific. We use trickle because we consider DIO
sending a consitency problem,
>hence we focus on the global information. They come both from parents
and childs, so I would also
>increment C when hearing from a child. Am I missing something?
>
>Julien
>

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 25 Nov 2009 08:08:08 +0100

Hi Pascal, Jonathan,

Thanks for your answers. I think we agree that child and other nodes
could play a role to detect a consistent situation. 
Hence, we need to see how this affects the DIO processing rules as you
actually typically don't process DIOs from node deeper than you in the
DAG...
I also agree with Pascal and Julien when they say that consistency
should concentrate on global or common DAG information.

Best,
Mathilde
-----Original Message-----
From: Pascal Thubert (pthubert) 
Sent: lundi, 23. novembre 2009 08:55
To: Julien Abeille (jabeille); 'Jonathan Hui'; Mathilde Durvy (mdurvy)
Cc: [email-masked]'
Subject: RE: [Roll] Trickle clarification: (in)consistency

Hi Julien

Pascal

>focus on the global information. They come both from parents and
childs, so I would also increment C when hearing from a child. Am I
missing something?
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Pascal Thubert (pthubert)
>> 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.