Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00

From: Mukul Goyal <[email-masked]>
Date: Tue, 18 May 2010 16:54:09 -0500 (CDT)

Hi Philip, JP

Here is a list of the controls that can be used to limit the spread of discovery messages:

1. If a node does not know the link cost, it wont forward the discovery message further (was implicit in the p2p draft; now would be made explicit);
2. If a node receives a discovery message advertizing a rank (in the temporary DAG) higher than the node's current rank, the discovery message is ignored;
3. If the discovery message has already traveled a certain "distance" (determined based on the rank that the receiving node would achieve in the temporary DAG using the rank advertized in the discovery message), it wont be forwarded any further;
4. If the end-to-end cost for the path taken by the discovery message so far already fails the "good enough" criteria, the discovery message is not forwarded any further; (this control is optional since the "good enough" criteria may be too difficult for a constrained intermediate node to calculate)
5. The trickle timer.

The trickle timer helps control the spread of discovery messages in following ways:
1. The timer's interval can be chosen to "speed up" the discovery message or "slow it" down; the tradeoff being the number of discovery messages generated. A large interval allows only one message to be sent in response to several received. 
2. The redundancy threshold of the trickle timer can optionally be used to further limit the generation of discovery messages. Do not generate your own discovery message if you have already received "n" messages advertizing the same/better rank or e2e cost than what you will advertize.

I guess a node could also employ a local policy regarding when and how many times to generate a discovery message:
1. generate discovery messages only a certain number of times;
2. do not generate a discovery message at the timer's firing if the rank/cost to be advertized is same as before;
2. always generate a discovery message at the timer's firing (irrespective of the redundancy threshold) if the new cost/rank to be advertized is better than before.

So, to answer your question:

"are you suggesting using Trickle as the route discovery mechanism, or as the data delivery mechanism? "

I would say that we are using trickle as an additional control over the generation of discovery messages.
 
Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "Mukul Goyal" <[email-masked]>, "Anders Brandt" <[email-masked]>, "roll WG" <[email-masked]>, "Emmanuel Baccelli" <[email-masked]>
Sent: Tuesday, May 18, 2010 10:36:46 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00

On May 18, 2010, at 2:24 AM, JP Vasseur wrote: 

[Anders] I understand your concern and if you have resources 

in a node for doing more intelligent forwarding decisions, this 

is wonderful. 

For the most constrained nodes, however, I love the simplicity 

of Trickle where you forward (randomized schedule) as long as 

you have picked up less than n copies of the discovery message 

from you direct range neighbors. 

But that requires to be cautious too since that could eliminate some "good" paths too, and 
in particular the ones that are better than the DODAG path. 

Anders -- are you suggesting using Trickle as the route discovery mechanism, or as the data delivery mechanism? 

Phil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 19 May 2010 05:44:46 +0200

Hi Mukul,

Few comments in line.

On May 18, 2010, at 11:54 PM, Mukul Goyal wrote:

> 1. If a node does not know the link cost, it wont forward the  
> discovery message further (was implicit in the p2p draft; now would  
> be made explicit);
> 2. If a node receives a discovery message advertizing a rank (in the  
> temporary DAG) higher than the node's current rank, the discovery  
> message is ignored;
> 3. If the discovery message has already traveled a certain  
> "distance" (determined based on the rank that the receiving node  
> would achieve in the temporary DAG using the rank advertized in the  
> discovery message), it wont be forwarded any further;
> 4. If the end-to-end cost for the path taken by the discovery  
> message so far already fails the "good enough" criteria, the  
> discovery message is not forwarded any further; (this control is  
> optional since the "good enough" criteria may be too difficult for a  
> constrained intermediate node to calculate)

Note that there are quite a few vague/hard to define parameters:  
"Certain" distance, "good enough" that will require more detailed  
explanations.

> 5. The trickle timer.

See my previous message .... you may because of that ignore a "better"  
path, the whole reason for using this P2P scheme.

> 1. The timer's interval can be chosen to "speed up" the discovery  
> message or "slow it" down; the tradeoff being the number of  
> discovery messages generated. A large interval allows only one  
> message to be sent in response to several received.
> 2. The redundancy threshold of the trickle timer can optionally be  
> used to further limit the generation of discovery messages. Do not  
> generate your own discovery message if you have already received "n"  
> messages advertizing the same/better rank or e2e cost than what you  
> will advertize.
>

Not a showstopper by all means but still lots of knobs difficult to  
define ...

> I guess a node could also employ a local policy regarding when and  
> how many times to generate a discovery message:
> 2. do not generate a discovery message at the timer's firing if the  
> rank/cost to be advertized is same as before;
> 2. always generate a discovery message at the timer's firing  
> (irrespective of the redundancy threshold) if the new cost/rank to  
> be advertized is better than before.
>

Which should be the case.

Thanks.

JP.

> Cc: "Mukul Goyal" <[email-masked]>, "Anders Brandt"  
> <[email-masked]>, "roll WG" <[email-masked]>, "Emmanuel Baccelli" <[email-masked] 
> >
> Anders -- are you suggesting using Trickle as the route discovery  
> mechanism, or as the data delivery mechanism?
>
>
> Phil
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll