Subject: [Roll] Scalability of P2P-RPL

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Mar 2012 17:51:58 +0200

Hi,

as I mentioned today on the microphone, I would be interested to see
results of the different deployments in terms of performance, overhead,
delay, required state etc.

Section 2 ("The Use Cases") says that:

   Another use case, common in a commercial building environment,
   involves a large LLN deployment where P2P communication along a
   particular DAG among hundreds (or thousands) of routers creates
   severe traffic congestion near that DAG's root, and thus routes
   across this DAG are desirable.

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

Regards
Ulrich

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 28 Mar 2012 11:09:12 -0500 (CDT)

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

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <[email-masked]>
To: "roll WG" <[email-masked]>
Sent: Wednesday, March 28, 2012 10:51:58 AM
Subject: [Roll] Scalability of P2P-RPL

Hi, 

as I mentioned today on the microphone, I would be interested to see results of the different deployments in terms of performance, overhead, delay, required state etc. 

   across this DAG are desirable. 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). 

Regards 
Ulrich 

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 28 Mar 2012 18:16:39 +0200

Mukul,

On Wed, Mar 28, 2012 at 6:09 PM, Mukul Goyal <[email-masked]> 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
> 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

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 28 Mar 2012 11:29:02 -0500 (CDT)

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" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "roll WG" <[email-masked]>
Sent: Wednesday, March 28, 2012 11:16:39 AM
Subject: Re: [Roll] Scalability of P2P-RPL

Mukul,

Regards
Ulrich

---

From: C Chauvenet <[email-masked]>
Date: Wed, 28 Mar 2012 23:13:55 +0000

Hi,

Le 28 mars 2012 à 18:29, Mukul Goyal a écrit :

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

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 ?

I think numbers are always dangerous in documents that need to be frozen at some point.
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.

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <[email-masked]<mailto:[email-masked]>>
To: "Mukul Goyal" <[email-masked]<mailto:[email-masked]>>
Cc: "roll WG" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Regards
Ulrich
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Mar 2012 08:33:27 +0200

Cédric,

On Thu, Mar 29, 2012 at 1:13 AM, C Chauvenet <[email-masked]> wrote:
> 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 :
>

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

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

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

---

From: C Chauvenet <[email-masked]>
Date: Thu, 29 Mar 2012 07:00:13 +0000

Ulrich, 

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

> be spelled out in the draft.

Sure, this would be useful to precise the scope.

Cédric.