Re: [Roll] Scalability of P2P-RPL

Ulrich, 

Le 29 mars 2012 à 08:33, Ulrich Herberg a écrit :

> Cédric,
> 
> On Thu, Mar 29, 2012 at 1:13 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:
>> Hi,
>> 
>> 
>> Le 28 mars 2012 à 18:29, Mukul Goyal a écrit :
>> 
>> Okay, but I think that should be explicitly mentioned in the use case
>> 
>> 
>> As discussed today during the meeting, numbers need to be placed given a
>> particular context.
>> So, if we put explicitly "4-5 hops" in the requirements, this has to be in
>> regards to the total number of nodes, the topology, the technology used, the
>> environment, and other numerous parameters that could justify this "4-5"
>> value for a particular case.
> 
> I am aware that the precise number of hops depends on a number of
> things. However, I think it should be spelled out that the draft has
> limitations in terms of scope and is not always applicable in general
> LLNs of thousands of nodes (at least that's what I infer from the talk
> yesterday).
> 
> 
>> For instance, if you consider 15.4 in the sub Ghz band, 15.4 in the 2.4 Ghz
>> band or PLC technology where RPL applies, the 4-5 hops physical distance
>> vary from at least one or two order of magnitude.
> 
> I doubt that the hop distance varies by two orders of magnitude, i.e.
> up to 500 hops (even one seems a lot).

I was thinking about 1 Vs 10, and this may be more if you compare RF 2.4 VS PLC across multiple floors in a building.

> 
>> So people working over the 2.4 Ghz may use the 4-5 hops boundary, whereas
>> people running over sub Ghz may be happy within a single hop boundary.
> 
> Sure, I never doubted that depending on the link layer / the topology
> / the traffic patterns etc there are differences in scope. I just
> request to add one sentence to make it clear to the reader what the
> applicability of the draft is.
> 
>> 
>> There is a section in the P2P draft that is quite generic, so applicable to
>> most of the use case,
>> and shed some light on the tradeoff regarding using
>> or not the P2P extension, and limit the scope of the flooding :
>> 
>> A network designer may take into consideration both the benefits
>> (potentially better routes;
>> no need to maintain routes proactively) and costs (control messages
>> generated during the route discovery process) when using P2P-RPL.
>> 
>> 
>> We may expand this sentence to be more precise on the flooding region.
>> 
>> What do you think ?
> 
> That can be done. But I also think that the Use Cases section should
> be more specific in which scenarios the draft can be used.
> 
> 
>> 
>> I think numbers are always dangerous in documents that need to be frozen at
>> some point.
> 
> I do not insist on fixed numbers, I am aware that the number 4 or 5
> was just named as example. But it was clear from them that the draft
> is limited to small-size networks (or at least close peers in a larger
> network). I don't say that this is a problem, but just that it should
> be spelled out in the draft.

Sure, this would be useful to precise the scope.

> 
> Best regards
> Ulrich

Cédric.

> 
>> But I agree that they are very relevant to share, when you want to leverage
>> on other experiments.
>> Putting fixed numbers in protocols that target very wide scope and emerging
>> applications is like asking to a commercial guy to put a fixed price on a
>> product for the 20 years to come !
>> 
>> Just my 2 cts
>> 
>> Cédric.
>> 
>> section (or somewhere else).
>> 
>> Sure. I will add text to that effect. Note that the tradeoff is not
>> straightforward: even when the P2P-RPL routes are not much shorter than
>> routes along a global DAG, they would still avoid traffic concentration
>> around the root.
>> 
>> Thanks
>> Mukul
>> 
>> ----- Original Message -----
>> From: "Ulrich Herberg" <ulrich@herberg.name>
>> To: "Mukul Goyal" <mukul@uwm.edu>
>> Cc: "roll WG" <roll@ietf.org>
>> Sent: Wednesday, March 28, 2012 11:16:39 AM
>> Subject: Re: [Roll] Scalability of P2P-RPL
>> 
>> Mukul,
>> 
>> On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal <mukul@uwm.edu> wrote:
>> 
>> 
>> I don't see anywhere in this section that the draft is only limited to
>> 
>> 4-5 hops, as mentioned today. If the protocol can run in larger networks but
>> 
>> only for routers in maximum hop distance of 4-5, that should be spelled out
>> 
>> (together with a warning that TTL of the control messages has to be set to
>> 
>> 4-5 to avoid network wide flooding).
>> 
>> 
>> P2P-RPL can certainly discover routes of any hop length, just that its
>> 
>> application would be most useful when the target is within 4-5 hops. If the
>> 
>> target is further out, the route along a global DAG might be almost as good.
>> 
>> This ofcourse depends on network topology and routing metrics in use etc.
>> 
>> 
>> Okay, but I think that should be explicitly mentioned in the use case
>> section (or somewhere else).
>> 
>> Regards
>> Ulrich
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> 
>> 
> 