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

[JP Vasseur <[e-mail]>]

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

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.

> Thanks
> Mukul
>
>
> ----- Original Message -----
> From: "JP Vasseur" <[e-mail]>
> To: "Anders Brandt" <[e-mail]>
> Cc: "Mukul Goyal" <[e-mail]>, "roll" <[e-mail]>
> 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:[e-mail] ]
> 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" < [e-mail] >
>
>
>
>
> To: [e-mail]
>
>
>
>
> 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
>
>
>
>
> [e-mail]
>
>
>
>
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
> _______________________________________________
>
>
> Roll mailing list
>
>
> [e-mail]
>
>
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>
>