Message info
 
To:Ulrich Herberg From:C Chauvenet Subject:Re: [Roll] Scalability of P2P-RPL Date:Thu, 29 Mar 2012 07:00:13 +0000
 

Ulrich,

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

> Cdric,
>
> 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

Cdric.

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


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll