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

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

Hi JP

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

>I can help provide some text, if that helps.

Sure, please send me the text you would like to see in the draft. Also, I wanted to point out that the purpose of the measurement messages is to help decide whether to initiate a reactive route discovery ot not. If the measurement of the cost of an existing (DAG-based) route indicates that this route is good enough, there wont be a need to do a reactive discovery. Further, the "good enough" criteria can be selected on the basis of information provided by measurement messages. If the measurement on a DAG-based route returns an end-to-end cost "x", the good enough criteria can be set to some fraction of x thereby ensuring that any discovered P2P routes have a certain minimum cost advantage over DAG-based route. Ofcourse, there may not exist any P2P routes with such advantage (and that's why we need to put in the text that you are suggesting).

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "Anders Brandt" <[email-masked]>
Cc: "Mukul Goyal" <[email-masked]>, "roll" <[email-masked]>
Sent: Tuesday, May 18, 2010 11:01:57 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00

Hi Anders, 

On May 17, 2010, at 4:18 PM, Anders Brandt wrote: 

Hi JP 

Please find comments inline 

- Anders 

From: JP Vasseur [ mailto:[email-masked] ] 
Sent: Monday, May 17, 2010 15:05 
To: Anders Brandt; Mukul Goyal 
Cc: roll 
Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll-p2p-rpl-00 

Hi Anders, 

Co-chair hat-off. 

I think that it goes in right direction. 

Few comments for the moment. 

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.   

What about: 
"The constraint to route only along a DAG potentially 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". 

JP> Why is it required to route across DAGs ? I guess that you meant "non DAG" routes ?   
  
Agreed. What the text should say is: 
"across a DAG", "across the branches of a dag" or "along non-DAG routes"  (pick one)   

I would choose "non DAG route" 

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

You misunderstood my point. The WG agreed that this was a MUST, I am not questioning the usefulness 
of it. I just meant to say that all implementations will not need it, that's all (thus the term optional). 

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

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. 

We're in sync. 

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. 

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. 

I can help provide some text, if that helps. 

Thanks. 

JP. 

Thanks. 

JP. 

On May 17, 2010, at 9:28 AM, Anders Brandt wrote: 

Hi all 

The P2P draft has been out for some weeks now. 
The team would like to poll the WG for directions whether this is 
the right approach. 

Phil has indicated some agreement. 
What about the rest of the WG? 

Others in favour of the work? 
Any alternative proposals? 

Otherwise the P2P team will conclude that we are on the right track 
and go on proposing specific frame format additions/modifications 
and mechanisms for RPL. 
When the required maturity is reached, those proposed additions/changes 
should be adopted by the RPL spec; thus obsoleting this draft. 

Thanks, 
 Anders 

On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote: 

Hi all 

The following draft has been submitted for WG's consideration. It 

describes the additional mechanisms required to support P2P 

routing in 

LLNs. The draft first provides a high level description of the 

mechanisms and then proposes one way of realizing these 

mechanisms in 

RPL. 

Regards 

Mukul 

----- Forwarded Message ----- 

From: "IETF I-D Submission Tool" < [email-masked] > 

To: [email-masked] 

Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada 

Central 

Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 

A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been 

successfully submitted by Mukul Goyal and posted to the IETF 

repository. 

Filename: draft-dt-roll-p2p-rpl 

Revision: 00 

Title: Mechanisms to Support Point-to-Point 

Routing in Low Power   

and Lossy Networks 

Creation_date: 2010-04-28 

WG ID: Independent Submission 

Number_of_pages: 13 

Abstract: 

This draft presents mechanisms to determine the end-to-end 

cost of an 

existing route and to discover/establish "on demand" one or more 

routes between two nodes in a low power and lossy network.   

This draft 

also proposes functionality that would enable RPL to 

provide these P2P 

mechanisms. 

The IETF Secretariat. 

_______________________________________________ 

Roll mailing list 

[email-masked] 

https://www.ietf.org/mailman/listinfo/roll 

_______________________________________________ 

Roll mailing list 

[email-masked] 

https://www.ietf.org/mailman/listinfo/roll 

_______________________________________________ 
Roll mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/roll

---

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

Hi Mukul,

On May 20, 2010, at 2:56 AM, Mukul Goyal wrote:

> Hi JP
>
>> 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
> Sure, please send me the text you would like to see in the draft.

Will do. I'll wait until you provide the next revision and I'll  
provide you some text.

> Also, I wanted to point out that the purpose of the measurement  
> messages is to help decide whether to initiate a reactive route  
> discovery ot not. If the measurement of the cost of an existing (DAG- 
> based) route indicates that this route is good enough, there wont be  
> a need to do a reactive discovery.

Understood, that does not remove the challenge of "what good enough"  
means, especially when you have a route that is neither bad nor  
excellent. You may end generating traffic to measure the DAG route via  
the measurement mechanism, potential trigger the reactive mechanisms  
and end up with a route that is not "much" better. No show-stopper, we  
just need to make it clear in the specification.

> Further, the "good enough" criteria can be selected on the basis of  
> information provided by measurement messages. If the measurement on  
> a DAG-based route returns an end-to-end cost "x", the good enough  
> criteria can be set to some fraction of x thereby ensuring that any  
> discovered P2P routes have a certain minimum cost advantage over DAG- 
> based route.

But you can only compare once you have both routes.

> Ofcourse, there may not exist any P2P routes with such advantage  
> (and that's why we need to put in the text that you are suggesting).
>

Exactly.

I'll provide some text for the next revision.

Thanks.

JP.

> 1)  o The constraint to route only along a DAG leading to  
> significantly suboptimal P2P routes and traffic congestion near the  
> DAG root.
> 2)  Such applications require a mechanism for "reactive route  
> discovery" and the ability to route "across DAGs".
>
>
> 3)  The mechanisms described in this document are intended to be  
> employed as complementary to RPL in specific scenarios that need  
> point-to-
> 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