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

From: Mukul Goyal <[email-masked]>
Date: Tue, 18 May 2010 00:46:20 -0500 (CDT)

Hi JP

Just adding my thoughts:

1)  o The constraint to route only along a DAG leading to significantly suboptimal P2P routes and traffic congestion near the DAG root. 
JP> You may want to soften the statement here since the path computed along the DAG  
may be sub-optimal .. it all depends on the destination, degree of meshing of the DAG, etc ... 
I think that the argument of not having to maintain route maintenance for some nodes is  
more compelling.   

[Anders]  
What about: 
"The constraint to route only along a DAG potentially leading to significantly 
suboptimal P2P routes and traffic congestion near the DAG root."   ? 

[Mukul]
I will modify the text to include the factors JP mentioned.

2)  Such applications require a mechanism for "reactive route discovery" and the ability to route "across DAGs". 

JP> Why is it required to route across DAGs ? I guess that you meant "non DAG" routes ?   
2)  Such applications require a mechanism for "reactive route discovery" and the ability to route "across DAGs". 

JP> Why is it required to route across DAGs ? I guess that you meant "non DAG" routes ?   

[Anders]  
Agreed. What the text should say is: 
"across a DAG", "across the branches of a dag" or "along non-DAG routes"  (pick one)   

[Mukul]
I prefer "non-DAG" routes. Much better than "across-DAG".

3)  The mechanisms described in this document are intended to be employed as complementary to RPL in specific scenarios that need point-to-
   point (P2P) routes between arbitrary nodes. 

JP> More specifically, I think that we agree that it will be part of RPL, as an optional mechanism.   

[Anders]  
Negative. 

RPL will never be able to deliver the required performance for home and 
building without decent support for battery operation and reactive self-healing. 

[Mukul]
JP, my thinking is that RPL should not characterize the P2P support as optional. It should be a "must". RPL is being designed to meet requirements of 4 application domains and atleast 2 of these domains have P2P as a critical requirement. 

4) Section 4.2: objective function 

JP> You actually do not need an OF for that. Just use the metrics specified in the Routing-metrics ID, 
adding a path-cost-bound object (for the "good enough" criteria).   
  
[Anders]
Great. This is an example of why it will be valuable for RPL as a whole if the WG starts discussing 
how to achieve the stated goals of the draft. 
OF or metrics - I leave it for the experts to decide which is the right thing. As long as I can ask for a 
"good enough" route as result of a reactive discovery. I need the lamp to turn on with low delay. 
Later, I may have time for fine-tuning the route.     

[Mukul]
We will create a separate ID for the "measurement request/reply" part. It would use the functionality provided by the Routing-metrics ID.  

5)  4.6. Transport of Routing Metrics The Metric Container option defined in RPL-07 can be used to carry
   both the aggregated end-to-end and the local values for the routing
   metrics being used to define the routing cost.  Additional metric
   objects may need to be defined to carry the aggregated end-to-end
   routing cost and a source-route unmodified from one node to another; 

JP> with regards to the second part of the paragraph I would suggest to use the same metrics as defined 
in the routing-metric ID. 

[Mukul]
I need to go back to the routing metrics ID to see what functionality it already provides and what additions do we need.

6) We just need to have a section somewhere indicating that such reactive mechanism has a cost too and the resulting 
path cost decrease is not known a priori and may end up being close to the DAG cost for that destination. I am not 
questioning the usefulness of the mechanism, just make sure to indicate it. 

[Mukul]
I will make sure that such text is added to the draft.

Thanks
Mukul

---

From: JP Vasseur <[email-masked]>
Date: Tue, 18 May 2010 09:11:57 +0200

Hi Mukul,

On May 18, 2010, at 7:46 AM, Mukul Goyal wrote:

> Hi JP
>
> Just adding my thoughts:
>
> 1)  o The constraint to route only along a DAG leading to  
> significantly suboptimal P2P routes and traffic congestion near the  
> DAG root.

OK

> 2)  Such applications require a mechanism for "reactive route  
> discovery" and the ability to route "across DAGs".
>
> 2)  Such applications require a mechanism for "reactive route  
> discovery" and the ability to route "across DAGs".
>
>

OK

> 3)  The mechanisms described in this document are intended to be  
> employed as complementary to RPL in specific scenarios that need  
> point-to-
> JP, my thinking is that RPL should not characterize the P2P support  
> as optional. It should be a "must". RPL is being designed to meet  
> requirements of 4 application domains and atleast 2 of these domains  
> have P2P as a critical requirement.
>

Let clarify again. ROLL will deliver a solution. This is not optional  
in the sense that we may do it or not do it. As you pointed out, this  
is a MUST requirements so we have to have a solution, and we're on the  
right track. That being said, that feature may not be required in all  
RPL implementations since there are a number of use case where this  
may not be required. As in many other protocols, not all features are  
required. That's all.

> We will create a separate ID for the "measurement request/reply"  
> part. It would use the functionality provided by the Routing-metrics  
> ID.
>

Excellent, thanks.

> I need to go back to the routing metrics ID to see what  
> functionality it already provides and what additions do we need.
>

OK let me know if you have any question.

> 6) We just need to have a section somewhere indicating that such  
> reactive mechanism has a cost too and the resulting
> path cost decrease is not known a priori and may end up being close  
> to the DAG cost for that destination. I am not

Thanks.

JP.