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

From: Mukul Goyal <[email-masked]>
Date: Wed, 19 May 2010 20:39:04 -0500 (CDT)

Hi JP

[Mukul]
> 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)

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

[Mukul]
The "distance" that the discovery messages may travel would be represented by a maximum limit on the rank in the temporary DAG. This maximum limit on rank I suppose is a configuration parameter. The "good enough" criteria may be tied up to the e2e cost of any existing DAG-based route or it could be a configuration parameter as well. 

Do you think that these two concepts are not well described in the draft?

[JP]
> 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.

[Mukul] 
Not sure how. A node would always generate a discovery message at the (periodic) expiry of the trickle timer if it has a better cost to advertize (unless the local policy some how prevents it from doing so).

[JP]
> 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.
>

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

[Mukul]
But these knobs are standard/integral part of a trickle timer.

Thanks
Mukul

---

From: JP Vasseur <[email-masked]>
Date: Thu, 20 May 2010 21:56:17 +0200

Hi Mukul,

On May 20, 2010, at 3:39 AM, Mukul Goyal wrote:

> The "distance" that the discovery messages may travel would be  
> represented by a maximum limit on the rank in the temporary DAG.  
> This maximum limit on rank I suppose is a configuration parameter.  
> The "good enough" criteria may be tied up to the e2e cost of any  
> existing DAG-based route or it could be a configuration parameter as  
> well.
>

There are described. If the document is adopted I'll make a detailed  
pass at WG chair shepherd and provide comments, suggest text, ...
Note one thing though. Be cautious not to end up with a mechanism with  
a large number of parameters the value of which would be
difficult to determine.

> Not sure how. A node would always generate a discovery message at  
> the (periodic) expiry of the trickle timer if it has a better cost  
> to advertize (unless the local policy some how prevents it from  
> doing so).
>

You just need to add a criteria to the trickle timers reset.

> But these knobs are standard/integral part of a trickle timer.

Again just be cautious not to add too many. Bear in mind, that  
recommended values should be provide before any IESG LC.

Thanks.

JP.