Subject: Re: [Roll] Moving forward with the protocol work

From: Mukul Goyal <[email-masked]>
Date: Thu, 30 Jul 2009 06:25:40 -0500 (CDT)

Hi JP

As a _protocol_, RPL is not yet complete. It needs addition of a good P2P solution at the least. I imagine it is possible to incorporate in RPL the route discovery and maintenance mechanisms discussed in draft-goyal-roll-dv-01 to achieve better P2P routing (basically building a DAG rooted at the destination during route discovery; pruning it afterwards and using this pruned DAG, limited to the the neighborhood of discovered routes, for route maintenance). I guess other mechanisms may also be possible.

As a _framework_ for all future ROLL work, RPL has a serious deficiency. RPL is too tightly interweaved with one particular loop prevention mechanism - the one based on DAGs. At present, it does not seem possible to use RPL with a different loop prevention/avoidance/detection+correction mechanism. Hence, RPL is not ready to serve as a general framework for future ROLL work. 

I think that RPL needs to be modified so that the use of DAGs becomes optional. Then, it will be possible to use RPL as a framework. Right now, it is not a framework.

Thus, it seems that more work is required before RPL is ready for WG status either as a protocol or as a framework.

I am not sure glossing over known deficiencies and rushing with WG status for RPL would serve any useful purpose. Rather than granting it a WG status now and trying to solve the problems later on, I would suggest the reverse route.

Regards
Mukul

To: "Mukul Goyal" <[email-masked]>
Cc: "Mischa Dohler" <[email-masked]>, "ROLL WG" <[email-masked]>
Sent: Tuesday, July 28, 2009 10:25:04 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Moving forward with the protocol work

Hi Mukul,

I would really like to get your answer on whether you support the  
adoption of RPL as good foundation to move forward, adopting it as a  
WG ID. Your comments are extremely valid, see in line:

On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote:

> Mischa,
>
> I am not speaking for Jerry but P2P flows are important in LLN  
> applications I am familiar with (which happen to be in commercial  
> building domain). I will have to go back to all the requirements  
> drafts but I would be surprised if other domains will not benefit  
> from an efficient P2P solution.
>
> The main question is why are we insisting on "one solution fits all"  
> approach??? Why can't we recognize that different applications have  
> different requirements and offer multiple solutions (including RPL).
>
> Let RPL be used by applications that find it useful but we should  
> not force RPL as the only solution available.
>
> In my view, RPL has the following three shortcomings:
>
> 1) Does not offer optimal/good P2P routing
> 2) Does not allow destinations other than LBRs to be advertised.  
> Note that this point and the previous one are independent.
> 3) Insistence on using DAG as the loop prevention mechanism.
>
> RPL is a good MP2P solution but we should not force it down the  
> throats of people who want good P2P routing as well.
>
> IETF has a long history of offering multiple solutions for a given  
> routing problem. We has multiple interior gateway protocols,  
> multiple MANET solutions, multiple OSPF-MANET solutions. Why can't,  
> and why should not, we have multiple ROLL solutions??
>
> I asked this question to JP right at the time the ROLL WG got a new  
> charter. The answer I got was - we will work on one solution for now  
> but we do not exclude other solutions.
>
> I think ROLL should offer multiple solutions and let an application  
> choose what fits it best.
>

Few things:

1) The ROLL routing protocol will have to support a good solution for  
P2P, this is a MUST requirement. For the time being a solution such as  
RPL is optimized for P2MP and P2MP and does support P2P but that MUST  
be improved. This was discussed and agreed yesterday during the WG  
meeting and on the mailing list. Next step is to work on this and your  
help will be greatly appreciated.
2) The DT will reply but RPL support the advertisements of destination  
other than LBRs
3) Loop detection: fully agree, I had proposed myself a solution but  
others may have other ideas. I personally think that this is one of  
the areas where we can borrow some ideas also from the DADR proposal.  
Again to be discussed on the list.
4) With regards to having more protocols, we are chartered to design  
one protocol for the time being. There is still lot of work to do, and  
the solution will continue to evolve. It is thus premature to think  
more than one protocol at this stage.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "Mischa Dohler" <[email-masked]>
> To: "Jerald P Martocci" <[email-masked]>
> Cc: "ROLL WG" <[email-masked]>
> Sent: Tuesday, July 28, 2009 6:41:00 PM GMT -06:00 US/Canada Central
> Subject: Re: [Roll] Moving forward with the protocol work
>
> Jerry, I am not sure this was already discussed at the meeting in  
> person
> but I think we are a little in a catch22 situation here since - as far
> as I remember - none of the requirement docs explicitly required  
> (MUST)
> p2p situations. I gather that the design team did take these documents
> as their working basis which is why p2p is not efficiently  
> supported. In
> our urban requirements draft, we actually did go as far as saying that
> p2p should not be the main design thrust but rather the highly
> directional data flows towards a few sinks. Mischa.
>
>
> [email-masked] wrote:
>>
>> I cannot yet affirm RPL as a working group draft since it hasn't yet
>> stated how P2P communication will operate within the DAG.
>>
>> As I have noted in my review comments, connectivity to every node  
>> within
>> the DAG is not assured.  The traffic patterns within the LLN are also
>> suspect since most packets must travel upward toward the LBR before
>> finding their intended destination lower in the DAG.  This imbalance
>> will create network traffic congestion in the higher layers of the  
>> DAG.
>> Hopping many hops up the DAG and back down the DAG to talk to a node
>> that is in direct radio range seems totally inefficient.
>>
>> Latency and convergence time are also a concern.  However, I can wait
>> for simulation or implementations to ferret out these issues.
>>
>> Regards,
>>
>> Jerry Martocci
>>
>>
>>
>>
>>
>> *JP Vasseur <[email-masked]>*
>> Sent by: [email-masked]
>>
>> 07/28/2009 11:36 AM
>>
>> 	
>> To
>> 	ROLL WG <[email-masked]>
>> cc
>> 	
>> Subject
>> 	[Roll] Moving forward with the protocol work
>>
>>
>> 	
>>
>>
>>
>>
>>
>> Dear WG,
>>
>> First of all, thanks for all the time and energy you all have devoted
>> during the past few weeks on the protocol work. There was excellent
>> followup discussion at the physical WG meeting.
>>
>> To the question "Do you think that RPL provides an adequate  
>> foundation
>> for the ROLL routing protocol work", there was clearly a good
>> consensus in the WG meeting. It was also recognized there are still
>> several open issues for which we WILL need help from many WG
>> contributors, including the authors of other documents.
>>
>> Could you please confirm (or not) the adoption of draft-dt-roll- 
>> rpl-01
>> as a WG document ?
>>
>> Then we will of course move to the next step.
>>
>> Thanks,
>>
>> JP and David
>>
>>
>> _______________________________________________
>> 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
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 30 Jul 2009 09:02:02 -0700

Hi Mukul,

I think RPL is a good candidate for the types of applications we see for
Smart Metering (which admittedly don't require optimized P2P).     The
options I have seen for distance vector routing with optimized P2P support
either require flooding (like AODV for example) or maintenance of large
state information within routing devices.

I read the various notes on concerns on loop prevention in RPL.  I don't
really see those mechanisms as being that heavy (I think you are referring
to the issuance of RAs and the text around frozen DAGs).  Could you
elaborate a bit more on why you see the loop avoidance mechanism in RPL as
being heavy and what the tradeoffs are in the alternative proposal, not
around loop avoidance, but the added maintenance and state information
required to rely on optimized P2P as the basis for ROLL.

Also, it seems to me that an optimized P2P solution could be built with the
DAG.  Assuming some changes were also made to loop avoidance wouldn't this
make more sense that trying to use an optimized P2P solution (which has
historically never scaled for all application spaces, hence the plethora of
MANET protocols).

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukul Goyal
Sent: Thursday, July 30, 2009 4:26 AM
To: JP Vasseur
Cc: ROLL WG
Subject: Re: [Roll] Moving forward with the protocol work

Hi JP

As a _protocol_, RPL is not yet complete. It needs addition of a good P2P
solution at the least. I imagine it is possible to incorporate in RPL the
route discovery and maintenance mechanisms discussed in
draft-goyal-roll-dv-01 to achieve better P2P routing (basically building a
DAG rooted at the destination during route discovery; pruning it afterwards
and using this pruned DAG, limited to the the neighborhood of discovered
routes, for route maintenance). I guess other mechanisms may also be
possible.

As a _framework_ for all future ROLL work, RPL has a serious deficiency. RPL
is too tightly interweaved with one particular loop prevention mechanism -
the one based on DAGs. At present, it does not seem possible to use RPL with
a different loop prevention/avoidance/detection+correction mechanism. Hence,
RPL is not ready to serve as a general framework for future ROLL work. 

I think that RPL needs to be modified so that the use of DAGs becomes
optional. Then, it will be possible to use RPL as a framework. Right now, it
is not a framework.

Thus, it seems that more work is required before RPL is ready for WG status
either as a protocol or as a framework.

I am not sure glossing over known deficiencies and rushing with WG status
for RPL would serve any useful purpose. Rather than granting it a WG status
now and trying to solve the problems later on, I would suggest the reverse
route.

Regards
Mukul

Hi Mukul,

Few things:

Thanks.

JP.