Re: [Roll] Scalability of P2P-RPL

[Ulrich Herberg <[e-mail]>]

Cédric,

On Thu, Mar 29, 2012 at 1:13 AM, C Chauvenet <[e-mail]> 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).

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

Best regards
Ulrich

> 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" <[e-mail]>
> To: "Mukul Goyal" <[e-mail]>
> Cc: "roll WG" <[e-mail]>
> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>