Subject: [Roll] mixture of storing and non-storing nodes

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 21 Aug 2012 09:31:38 -0700

Dear ROLL WG,

John Ko posted a draft a few days ago about how we might accommodate a
mixture of storing and non-storing nodes in a network more efficiently
than making one of them leaf nodes. Searching through the ROLL mail
archives, it was clear at the time that there was no use case for
having a network that has a mixture of storing and non-storing nodes.
I wonder if this is necessarily true if there are devices from
multiple vendors. At the time, it was also speculated that the mixture
could also introduce unknown problems and no one seems to have a
working solution. The draft describes one of the problems that could
occur if we try to form a multi-hop network with storing and
non-storing nodes. That is a concrete first step towards getting a
handle on the challenge of having nodes with different capabilities in
a network.

Your guidance on whether this is an important problem worth working on
or the work is heading in a wrong direction would help evolve or stop
the work.

Thanks.

- om_p

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Wed, 22 Aug 2012 06:15:05 +0000

Hi,

> or the work is heading in a wrong direction would help evolve or stop

JP> I cannot agree more - actually we even have a partial to the problem during the initial design phase and
the WG collectively decided not to mix storing and non-storing in light of the added complexity. I would also
appreciate the feedback of the WG on this, and not add complexity unless this becomes a strong requirement.

Thanks.

JP.

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

---

From: JeongGil Ko <[email-masked]>
Date: Wed, 22 Aug 2012 23:35:31 +0900

JP,

Thanks for your input! I fully agree that the added complexity should be minimal. We have a poster at this year's SenSys indicating that the overhead of supporting the 'mixed' mode only requires minimal additional complexity. One of the design goals in designing the scheme was to minimize the additional overhead on non-route storing devices since, in most cases, these are the devices that will actually operate with strict memory/complexity requirements. Nevertheless the additional memory required to implement the scheme for both types of devices, storing and non-storing, (which we've done experimentally with TinyOS and NanoQplus implementations) is minimal.

To think about it, things get more complicated if we try to define an entirely new mode for hybrid operations, but, storing mode and non-storing mode both have their own benefits. Since the draft talks about a case where we can still preserve the nature of the two modes AND allow them to interoperate, I believe that this is a meaningful draft for the WG.

Thanks!

-John

------
JeongGil Ko, Ph.D.
Researcher
Electronics and Telecommunications Research Institute (ETRI)
http://sites.google.com/site/jeonggilko/

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Fri, 24 Aug 2012 05:06:14 +0000

Hi,

> To think about it, things get more complicated if we try to define an entirely new mode for hybrid operations, but, storing mode and non-storing mode both have their own benefits. Since the draft t…

Many Thanks for your feed-back, great discussion. If we have sufficient requirements for such a case (let's see what the WG says)
and minimal changes required to meet the requirements, why not, but I just wanted to raise the concern.

Thanks.

JP.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Aug 2012 14:32:33 -0400

OG> John Ko posted a draft a few days ago about how we might accommodate a
    OG> mixture of storing and non-storing nodes in a network more efficiently
    OG> than making one of them leaf nodes. Searching through the ROLL mail
    OG> archives, it was clear at the time that there was no use case for
    OG> having a network that has a mixture of storing and non-storing
    OG> nodes.

    JP> I cannot agree more - actually we even have a partial to the
    JP> problem during the initial design phase and the WG collectively
    JP> decided not to mix storing and non-storing in light of the added
    JP> complexity. I would also appreciate the feedback of the WG on
    JP> this, and not add complexity unless this becomes a strong
    JP> requirement. 

I believe that use cases for storing and non-storing nodes would appear
as optimizations (particularly in the p2p heavy LLNs) if we could figure
out how to make it work.

I think that the major problem was that nodes below the root needed to
know if there downstreams nodes were storing or not, and thus
non-storing nodes wound up picking up significant resource impact, when
those nodes were supposed to be lighter weight.

-- 
Michael Richardson
-at the cottage-

---

From: 정종수 <[email-masked]>
Date: Sat, 25 Aug 2012 00:33:07 +0000

Hi Michael.

> as optimizations (particularly in the p2p heavy LLNs) if we could figure

You're right. Additionally, mixture of storing and non-storing nodes can cause inefficient upwards routing in the current RPL. Because nodes that can support only different MOP from the root's MOP should act as a leaf node. Furthermore, if the leaf node is an only node that is at intermediate place physically to forward upstream traffic, not only downwards but also upwards routing will not work from this point.

> those nodes were supposed to be lighter weight.

Thank you.
-Jongsoo

---

From: JeongGil Ko <[email-masked]>
Date: Sat, 25 Aug 2012 11:14:18 +0900

Hi!

A bit more comments in-line ;)

>> those nodes were supposed to be lighter weight.

Resource is by far one of the most important factors. One of the characteristics of this draft is to allow both modes to be possible. If you have the resources, then be a storing mode! If not, you always have the option of being a non-storing mode... its just that with the draft, we can mix these two modes together. The two modes have their own benefits so let's keep them and allow them to mix together so that we can perform, as mentioned above, optimizations to the RPL network.

Thanks for your feed back!

-John