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

From: Mukul Goyal <[email-masked]>
Date: Thu, 20 May 2010 17:15:40 -0500 (CDT)

Hi Philip

[Mukul1]
>>> Note that we chose not to go deep into metrics/"routing cost" discussion in the p2p draft, simply because different people have very strong and very different opinions on what is right and what is wrong. 
> 
[Philip1]
>> I'm sorry; I need to argue this point. This isn't a question of opinion. It's a question of overwhelming scientific evidence and deployment experiences from real networks. Here are two simple published studies[1,2].
> 
[Mukul2]
> You are ignoring the fact that there are scenarios (especially, in home automation environment; Anders may back me up on this), where a device can not maintain any neighbor-specific state (e.g. the cost of the link to the neighbor or even the identity of the neighbor). You can not argue that hop-count should not be used even in such situations. It may be a bad metric in general but it may still be the only metric that can be used in a given situation.

[Philip2]
Why can't a device maintain any neighbor-specific state? We need a stateless protocol? I do not recall this from the application requirement documents; please correct me if I'm wrong.

[Mukul3] I think this discussion is going on wrong track. The route discovery mechanism needs to be metric agnostic. The route discovery protocol can not preclude the use of certain metrics, even the bad ones. 
*****************************************************************************************************
[Mukul1]
>>> A node should not forward a Discovery message further if it does not have the relevant link-level cost estimates.
> 
[Philip1]
>> I think that is this is changed to MUST NOT, then it could be OK. Or how about
> 
> "A node MUST NOT forward a Discovery message from a node for which it does not have relevant link-level metric information."
> 

[Mukul2]
> I am OK with changing "should not" to "MUST NOT". There is a problem with the text you suggested. Suppose a _forward_ route is being discovered as per a certain routing metric. Node B receives a discovery message from node A. As per your text, node B must not forward the message further if cost B->A is unavailable/bad.

[Philip2]
I think you might be reading too much into the text -- "relevant link-level metric information" could imply A->B or B->A. Hence the word "relevant."

[Mukul2]
> But, cost B->A is irrelevant in this case. Your text assumes that routing metrics are symmetrical enough to conclude that link A->B must be bad if link B->A is bad. Whether this assumption is valid or not depends on the definition of the routing metric/cost and is not some thing that should concern the route discovery protocol. The route discovery protocol needs to be agnostic about the metrics being used. Would you be OK with the text I suggested with "MUST NOT" replacing "should not":
> 
> A node MUST NOT forward a Discovery message further if it does not have the relevant link-level cost estimates.

[Philip2]
This seems a bit too vague for me -- what link-level cost estimates are relevant?

How about

"A node MUST NOT forward a Discovery message from a node if it does not have relevant link-level metric information for the link between the two."

[Mukul3]
So, the underlying assumption is that if node B receives a discovery message from node A, the relevant (A->B or B->A) link cost information would be available on B?? If this assumption is perceived as valid for all metrics, I am OK with your text. Infact, in that case, the assumption would need to go in text as well. But then we will be making an assumption about the routing metrics that can be used. I think my text is better even though vague.
******************************************************************************************************* 
[Mukul1]
>>> Note that we can not really refer to the "neighbor table" as you had suggested earlier.
> 
[Philip1]
>> Why?
[Mukul2]
> Because, a neighbor table may not exist since nodes are too constrained to maintain per-neighbor states.

[Philip3]
The core upward protocol is written under the premise of neighbor sets, parent sets, and preferred parents; if this terminology is invalid then we should go back to the drawing board. Can you point me to the document where this is stated? We can't have it both ways: efficient P2P and no state. I'd argue that for such nodes, you should route through their preferred parent. Stateless on-demand is a recipe for disaster.

[Mukul3]
I do not see a need to _require_ neighbor tables for the reactive route disovery part. Neighbor tables are _required_ to maintain link-level values for certain routing metrics. But, the reactive route discovery part has to be metric agnostic. I am going to go back to RPL specs to see the context in which it refers to the neighbor tables. May be we will have another point to argue about. ;)

Thanks
Mukul

---

From: Philip Levis <[email-masked]>
Date: Fri, 21 May 2010 09:25:44 -0700

On May 20, 2010, at 3:15 PM, Mukul Goyal wrote:

>>
> [Mukul2]
>> You are ignoring the fact that there are scenarios (especially, in  
>> home automation environment; Anders may back me up on this), where  
>> a device can not maintain any neighbor-specific state (e.g. the  
>> cost of the link to the neighbor or even the identity of the  
>> neighbor). You can not argue that hop-count should not be used  
>> even in such situations. It may be a bad metric in general but it  
>> may still be the only metric that can be used in a given situation.
>
> [Philip2]
> Why can't a device maintain any neighbor-specific state? We need a  
> stateless protocol? I do not recall this from the application  
> requirement documents; please correct me if I'm wrong.
>
> [Mukul3] I think this discussion is going on wrong track. The route  
> discovery mechanism needs to be metric agnostic. The route  
> discovery protocol can not preclude the use of certain metrics,  
> even the bad ones.

I have to disagree that this is the wrong track. It seems like a  
novel requirement has appeared, and this requirement is the  
justification for a technical decision. I'm wary of this, as it could  
be a post-facto justification for a particular approach. If it is a  
real requirement, then we need to examine the rest of the protocol in  
light of it. For example, if a node only has a single node in its  
neighbor set, then datapath validation may not work very well.

Phil