Subject: [Roll] non-storing mode vs storing mode

From: Rahul Jadhav <[email-masked]>
Date: Thu, 21 Jul 2016 11:37:21 +0200

In general the tone in ROLL WG seems to be in favor of non-storing mode of operation … To this effect, Carsten even made a statement yesterday “Storing mode doesn’t exist” while presenting his draft on constrained cast.

I don’t truly understand on why non-storing mode is the de-facto mode favoured… (quite possible that this is already discussed on WG before but i could not find a ref!)

My point is,
There seems to be an obvious design limitation with regards to Non-storing mode in context to multi hop networks…. i.e. if the number of hops goes several tens of hops (as mentioned in ami-applicability draft), then the IP header bulges because of the source routing header(SRH). Even with the latest proposals on compressing the SRH, the overhead per packet is still “too” significant considering for e.g. a 20 hops networks. Use of non-storing mode will result in significant increase in fragmentation which is not desirable in LLNs.

i understand that the non-storing mode significantly reduces the memory/complexity requirements… but the trade-off is now between cost and technical infeasibility!

Also, all the major open sources (Contiki, RiOT, unstrung) seems to have adopted storing-mode first … 

Thanks,
Rahul

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 02:52:20 -0700

On Thu, Jul 21, 2016 at 11:37:21AM +0200, Rahul Jadhav wrote:
> In general the tone in ROLL WG seems to be in favor of non-storing mode of operation ??? To this effect, Carsten even made a statement yesterday ???Storing mode doesn???t exist??? while presenting his draft on constrained cast.
> 
> I don???t truly understand on why non-storing mode is the de-facto mode favoured??? (quite possible that this is already discussed on WG before but i could not find a ref!)

An eample of the smallest RPL topology in which storing mode is seen infeasible would be nice.

> My point is,
> There seems to be an obvious design limitation with regards to Non-storing mode in context to multi hop networks???. i.e. if the number of hops goes several tens of hops (as mentioned in ami-applicability draft), then the IP header bulges because of the source routing header(SRH). Even with the latest proposals on compressing the SRH, the overhead per packet is still ???too??? significant considering for e.g. a 20 hops networks. Use of non-storing mode will result in significant increase in fragmentation which is not desirable in LLNs.
> 
> i understand that the non-storing mode significantly reduces the memory/complexity requirements??? but the trade-off is now between cost and technical infeasibility!
> 

The bloom filter comes to mind as a way to compress the SRH. Unicast is just a special
case of small group multicast ;-)

Cheers
    Toerless

> Also, all the major open sources (Contiki, RiOT, unstrung) seems to have adopted storing-mode first ??? 
> 
> Thanks,
> Rahul
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

-- 
---
Toerless Eckert, [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jul 2016 11:54:58 +0200

> I don’t truly understand on why non-storing mode is the de-facto mode favoured… (quite possible that this is already discussed on WG before but i could not find a ref!)

It is not really the favored mode.

It just happens the other mode is fatally broken.
Storing mode presumes infinite space at each router, or perfect
knowledge that your topology will never cause you to exceed that space,
or that each router is expendable and can rescind at any point in time
when its state space is exhausted (with the resulting massive
instability because that rescinding will cause the next router to fall
over).

Until we advance more on the hybrid approach, storing mode unfortunately
doesn't exist.

(I'd like to learn more about your 20-hop networks, but as I hinted,
bloom filters might help there, too.)

Grüße, Carsten

---

From: Oleg Hahm <[email-masked]>
Date: Thu, 21 Jul 2016 12:09:03 +0200

Hi Carsten!

> instability because that rescinding will cause the next router to fall

Two questions:
1.) Don't we have a similar problem for ND? Without prior knowledge about the
    network's density and assuming that IP addresses for a particular
    link-layer are *not* derived from the L2 address, one needs infinite space
    for the neighbor cache.
2.) Doesn't need a RPL root node also require infinite space without prior
    knowledge of your network size? If you know the number of nodes in your
    network than this can also serve as an upper bound for the FIB also in
    storing mode. (Sure, this might not be suitable for class devices in big
    networks.)

Cheers,
Oleg

---

From: Cenk Gündogan <[email-masked]>
Date: Thu, 21 Jul 2016 12:28:53 +0200

Am 21.07.2016 11:55 schrieb "Carsten Bormann" <[email-masked]>:
>
> Rahul Jadhav wrote:
> > In general the tone in ROLL WG seems to be in favor of non-storing mode
of operation … To this effect, Carsten even made a statement yesterday
“Storing mode doesn’t exist” while presenting his draft on constrained cast.
> >
> > I don’t truly understand on why non-storing mode is the de-facto mode
favoured… (quite possible that this is already discussed on WG before but i
could not find a ref!)
> It just happens the other mode is fatally broken.
I wouldn't mark the storing mode as ultimately broken.
It works, but it does not scale well. If you have a use case for
small-sized / sparse topologies, then there should be enough space
available in each nodes' rib/fib to store the (destination;next-hop) pairs
of the sub-DODAG.
Related to this: is there actually any work that aims to reduce the space
needed for (destination;next-hop) pairs? For simple RPL only networks e.g.
I can imagine that based on the DODAG Id some prefixes could be dropped /
assumed when doing a longest prefix match.

> instability because that rescinding will cause the next router to fall
There is still the possibility to request DAO-ACKs and choose e.g. another
parent if the ACK has a negative result (could not store DAO). Whether this
approach is good or bad is of course another question. But yeah, basically,
the problem remains if all routers on every upward path have no memory left.

> Until we advance more on the hybrid approach, storing mode unfortunately
+1 on the hybrid approach. I assume you refer to the DAO projection draft
from Pascal?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jul 2016 08:17:44 -0400

> “Storing mode doesn’t exist” while presenting his draft on constrained

Carsten makes some very good points about unknown limits.

There are networks where the nodes are much less constrained and are
often mains powered, but the radio space is very congested.  An example is
electric metering.  The fan-out on those networks is generally very low,
with the mesh often being 10 or 20 nodes deep, but only one node wide.
(A "string bean" is the word that comes to my mind).

I hope that the DAO-projection document will get some more mindshare soon.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 21 Jul 2016 14:35:36 +0200

> On Jul 21, 2016, at 11:54 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Rahul Jadhav wrote:
I stand corrected. Thanks. 

> instability because that rescinding will cause the next router to fall

Yes, this is a problem with storing mode and has implications on the node/solution costing. But many times, I work with requirements in the form of max number of nodes to be supported, in which case the network cardinality is known…. the unknowns usually are in the form of node density and the max hops required since they hugely differ from deployment to deployment.

> bloom filters might help there, too.)
My 20-hop network was an example from ami-applicability draft (where it actually says, several tens of hops) … Having said that it will be nice to discuss about pragmatic conditions for such networks. Thanks.

---

From: Joakim Eriksson <[email-masked]>
Date: Thu, 21 Jul 2016 14:45:44 +0200

Hello,

We have at Yanzi / SICS managed to handle networks larger than 100 nodes with storing mode and a configuration
that is 10 IPv6 neighbors and 20 RPL routes - and achieved good stability. But the RPL specification is very underspecified
when it comes to DAO and DAO ACK handling. I am more or less sure we also could scale to 1000 nodes if that would make
sense (but data rates will be so limited per node).

The major problem is very dense networks - here you will need to have a smart policy how to handle under provisioning of
routing and neighbor tables - otherwise the mentioned massive instability occurs...

Best regards,
— Joakim Eriksson, SICS

> On 21 Jul 2016, at 14:35, Rahul Jadhav <[email-masked]> wrote:
> 
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 06:06:59 -0700

> assumed when doing a longest prefix match.

Btw: One problem overall is that the RPPL routing protocols is in a working
group that comes primarily from one use case side (as its name implies).

For example, in autonomic networking (ANIMA) for our original charter
networks enterprise/SP, we use RPL, and storing mode is perfectly fine,
even with eg: 20,000 nodes. The memory/CPU requirements for this are 
insignificant on the SP platforms. Topologies can be up ?50 hops.
The closer to the edge you get the lower the resource consumption
(fewer routes). Matches perfectly the "towards the edge, equipment
gets smaller" deployment model.

Hey i am fine with "fundamentally broken and proud of it" ;-))

Cheers
    Toerless