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

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

Philip

>> 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. 

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

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.

>> A node should not forward a Discovery message further if it does not have the relevant link-level cost estimates.

>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."

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. 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.

>> Note that we can not really refer to the "neighbor table" as you had suggested earlier.

>Why?

Because, a neighbor table may not exist since nodes are too constrained to maintain per-neighbor states.

Thanks
Mukul

---

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

Hi,

On May 18, 2010, at 7:41 PM, Mukul Goyal wrote:

> Philip
>
>>> 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.
>
>> 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].
>
> 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.
>

I agree that the mechanism should stay "agnostic" to the metric in use  
and should support different kind of metrics similarly to RPL (base  
spec) in general.

>>> A node should not forward a Discovery message further if it does  
>>> not have the relevant link-level cost estimates.
>
> "A node MUST NOT forward a Discovery message from a node for which  
> it does not have relevant link-level metric information."
>
> 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. 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.

Agree.

> Would you be OK with the text I suggested with "MUST NOT" replacing  
> "should not":
>

Yes, just add a short justification.

> A node MUST NOT forward a Discovery message further if it does not  
> have the relevant link-level cost estimates.
>
> Because, a neighbor table may not exist since nodes are too  
> constrained to maintain per-neighbor states.
>
> Thanks
> Mukul
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

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

Hi JP,

>>> not have the relevant link-level cost estimates.
[Philip]
> it does not have relevant link-level metric information."

[Mukul]

> Would you be OK with the text I suggested with "MUST NOT" replacing  

[JP]

[Mukul]

Will do.

Thanks
Mukul

---

From: Philip Levis <[email-masked]>
Date: Thu, 20 May 2010 10:12:00 -0700

> 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…

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.

> 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.

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."

> 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":
> 

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."

> Because, a neighbor table may not exist since nodes are too constrained to maintain per-neighbor states.

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.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Thu, 20 May 2010 18:09:15 +0200

Thanks Mukul,