Subject: [Roll] Establishing downward routes in RPL : storing / non-storing / mixed modes of operation

From: Tim Winter <[email-masked]>
Date: Tue, 09 Mar 2010 10:23:47 -0500

WG,

In the RPL-07 proposal the DAO mechanism described in Section 6 attempts to support
operation with a mix of storing nodes and non-storing nodes- where storing nodes may
be provisioned with enough memory that they are capable to provision hop-by-hop
downward routes learned from DAO messages, and non-storing nodes would rely on source
routing for downward routes.  The present proposal describes operation in a mixed
mode operation, with both storing and non-storing nodes, where each node may
provision downward routing state as according to its capabilities and largely
independent of its position in the LLN topology.

It has been noted that operation in the case where all nodes (except possibly the
root) are non-storing nodes allows for certain optimizations, and that the case where
all nodes (except possibly leaves) are storing leads to other optimizations.  It has
also been noted that in the mixed cases the ability to provide an optimal solution
may break down.  In particular there are concerns about the complexity and
correctness of mixed-mode operation as proposed by RPL-07.

With this in mind, should RPL allow for operation in a mixture of storing/non-storing
nodes?  Or should each RPL Instance be exclusively operating in either storing or
non-storing mode (with the provision that operation as a leaf is always an option)?
(The non-mixed case may imply some control flag or equivalent given in the DIO to
signal the mode of operation).

-Tim

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Mar 2010 10:46:15 -0500

>>>>> "Tim" == Tim Winter <[email-masked]> writes:
    Tim> It has been noted that operation in the case where all nodes
    Tim> (except possibly the root) are non-storing nodes allows for
    Tim> certain optimizations, and that the case where all nodes
    Tim> (except possibly leaves) are storing leads to other
    Tim> optimizations.  It has also been noted that in the mixed cases
    Tim> the ability to provide an optimal solution may break down.  In
    Tim> particular there are concerns about the complexity and
    Tim> correctness of mixed-mode operation as proposed by RPL-07.

To summarize my understanding:
   root nodes always have to store
   leaf nodes never have to store
   it is intermediate nodes that in question

    Tim> With this in mind, should RPL allow for operation in a mixture
    Tim> of storing/non-storing nodes?  Or should each RPL Instance be
    Tim> exclusively operating in either storing or non-storing mode
    Tim> (with the provision that operation as a leaf is always an
    Tim> option)?  (The non-mixed case may imply some control flag or
    Tim> equivalent given in the DIO to signal the mode of operation).

I note that intermediate nodes that can store should clearly be able to
operate in non-storing mode.

I am favour of the RPL Instance being exclusively storing or
non-storing.   This significantly reduces the testing complexity.

I also suggest that non-storing operation be a MUST and storing
operating be a MAY.   

If one comes to assemble a bunch of equipement from different vendors,
it would be acceptable to discovery that they can interoperate in a
given physical configuration only in non-storing mode. 

(A different physical configuration might well permit all of the
non-storing only nodes to be leaves)

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 9 Mar 2010 08:00:03 -0800

Hi Tim,

I would be in favor of operating ROLL RPL as either all storing or all
non-storing.  However, I have the following concerns around this:

1)  Obviously, the choice would be a deployment concern if either storing
MAY be supported or non-storing MAY be supported, however, this would only
work in a closed system.  Introducing a non-storing device in a network of
all storing devices would not allow downward routing.  Introducing a storing
device in a network of all non-storing devices would only work if you MUST
use source routing (an odd feature selection for a storing device that
expects others in its network to be storing devices)

2)  The suggestion to make non-storing MUST and storing MAY drags in source
routing as a MUST.  There are instances where source routing won't work
(DAGs with sufficient depth where the source routing header frame exceeds a
6LowPAN single fragment according to the 6LowPAN reflector, for
example.....).  It would be a shame to have source routing as a MUST in
deployments where source routing does not even work for the application
profile.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Winter
Sent: Tuesday, March 09, 2010 7:24 AM
To: ROLL WG
Subject: [Roll] Establishing downward routes in RPL : storing / non-storing
/ mixed modes of operation

WG,

In the RPL-07 proposal the DAO mechanism described in Section 6 attempts to
support
operation with a mix of storing nodes and non-storing nodes- where storing
nodes may
be provisioned with enough memory that they are capable to provision
hop-by-hop
downward routes learned from DAO messages, and non-storing nodes would rely
on source
routing for downward routes.  The present proposal describes operation in a
mixed
mode operation, with both storing and non-storing nodes, where each node may
provision downward routing state as according to its capabilities and
largely
independent of its position in the LLN topology.

It has been noted that operation in the case where all nodes (except
possibly the
root) are non-storing nodes allows for certain optimizations, and that the
case where
all nodes (except possibly leaves) are storing leads to other optimizations.
It has
also been noted that in the mixed cases the ability to provide an optimal
solution
may break down.  In particular there are concerns about the complexity and
correctness of mixed-mode operation as proposed by RPL-07.

With this in mind, should RPL allow for operation in a mixture of
storing/non-storing
nodes?  Or should each RPL Instance be exclusively operating in either
storing or
non-storing mode (with the provision that operation as a leaf is always an
option)?
(The non-mixed case may imply some control flag or equivalent given in the
DIO to
signal the mode of operation).

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

---

From: Anders Jagd <[email-masked]>
Date: Tue, 9 Mar 2010 11:18:33 -0500

Tim,

I don't see that we would benefit from going as far as generally
dis-allowing a mix of storing/non-storing. Granted, most networks would
likely in practice be either storing on non-storing. However, I am not
convinced there would not be use cases justifying a mix.

Rather than tying our hands on this, would it not be better to have each OF
set rules/requirements for nodes to be "all storing", "all non-storing", or
"mix" ?

I actually don't think we are able to properly answer questions like this
properly before applicability work has been done - which is the main reason
I don't think we should go so far as to dis-allow a mix quite yet.

/Anders

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 9 Mar 2010 08:23:32 -0800

To reiterate some of my messages in the past, I have been against  
mixing of storing and non-storing nodes.  To indicate why, let me  
highlight some of the issues.

Supporting mixed mode operation effectively is a problem of managing  
distributed state.  What makes this problem difficult in mixed-mode  
networks is the difficulty in tracking where state is being stored and  
keeping that state up-to-date, since only select nodes are storing  
such state.  Specifically in RPL, it requires knowing which ancestor  
particular DAO state is being maintained and sending DAO messages at  
appropriate times when the ancestor changes.  In the fully storing  
case, the ancestor is simply the parent and easy to detect.  In the  
fully non-storing case, the ancestor is always the root, so again a  
node only needs to send updates if its immediate parent changes.  In a  
mixed mode case, ideally the node would know which node is storing its  
DAO information (it may not be the immediate parent or even the first  
storing node) when that node changes.

The existing RPL draft punts on this problem because we haven't come  
up with a good simple solution.  Early drafts specified that if a non- 
storing node is triggered to send DAOs (e.g. due to a single link  
failure), it must trigger DAOs from its descendants as well.  This can  
lead to O(N) messages due to a single link failure.  The 'S' bit  
helped to optimized for the fully non-storing case by indicating if  
there is a storing node that is not the root, reducing to O(1) for a  
single link failure.  But doesn't help much in mixed-mode environments  
where the true worst-case is still O(N).

To maintain some kind of interoperability, I would say that every node  
MUST at least be able to operate in leaf mode, regardless of whether  
it supports only storing or only non-storing.

--
Jonathan Hui

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Mar 2010 11:50:14 -0500

>>>>> "Anders" == Anders Jagd <[email-masked]> writes:
    Anders> I don't see that we would benefit from going as far as
    Anders> generally dis-allowing a mix of
    Anders> storing/non-storing. Granted, most networks would likely in
    Anders> practice be either storing on non-storing. However, I am not
    Anders> convinced there would not be use cases justifying a mix.

The amount of testing you need to do goes up considerably when you have
some nodes that can store and some that do not.

If we later find a use for a mixed network, it is much easier to relax a
rule when we iterate from Proposed Standard (step1 RFC) to Draft
Standard (step2 RFC) than it is to tighten up a rule and make some
implementations non-compliant.

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 9 Mar 2010 08:50:10 -0800

Hi Anders,

On Mar 9, 2010, at 8:18 AM, Anders Jagd wrote:

> I don't see that we would benefit from going as far as generally dis- 
> allowing a mix of storing/non-storing. Granted, most networks would  
> likely in practice be either storing on non-storing. However, I am  
> not convinced there would not be use cases justifying a mix.
>
> Rather than tying our hands on this, would it not be better to have  
> each OF set rules/requirements for nodes to be "all storing", "all  
> non-storing", or "mix" ?

The decision of whether or not we allow a mix may have a significant  
impact on how we design the DAO mechanism(s).  Going either way would  
be effectively "tying our hand" in what the solution will look like.

> I actually don't think we are able to properly answer questions like  
> this properly before applicability work has been done - which is the  
> main reason I don't think we should go so far as to dis-allow a mix  
> quite yet.

We do have routing requirements docs that are guiding us.  Did any of  
those point out the need for mixed-mode operation?

In any case, I don't think we are in a position to properly specify a  
DAO mechanism that supports mixed-mode operation effectively.  AFAIK,  
all existing production deployments within this space do not allow a  
mix storing and non-storing routing nodes.  It's fair to say that this  
WG has tremendous experience and understanding of solutions that can  
effectively address a particular mode.  But so far we have not seen a  
good proven solution for supporting mixed-mode environments.  Going in  
without a proven and well-understood solution worries me and I  
wouldn't want to start a research project here.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Mar 2010 17:55:01 +0100

Hi Jonathan and all,

One thing is I'm not happy with the S bit. I do not think we understand
fully what makes it work or when. Also, it implies an inner behavior in
the root, and probably also implies a tree structure. And like Jonathan
explains below, the worst case has not changed.

I think that the problem that Jonathan discusses, the O(N) stuff and the
need for DTSN that came with it, is a consequence of the behavior of the
cache in the current RPL (07); specifically, the caching nodes are
expected to absorb a piece of source route, and reinsert that piece on
the fly for forward packets. This is in fact a complex behavior. An
alternate behavior could be to optionally cache the source route piece,
but in any case let the full source route info through. 

With that alt behavior, then the source route steps would go up to the
root and the need for the S bit mechanism would go away. The root would
then insert all the source route step in a loose Routing Header. The
intermediate caches would be useful only for the P2P traffic within the
DODAG to avoid systematically going through the root. Cost compared to
the current behavior is bigger (control and data) packets in normal
conditions. 

So:
- I agree that the current behavior introduces too many problems and I
prefer that all the steps  in the source route reach the top, without
being absorbed by intermediate caches. I understand that this is what
people really want here,  and that can be done without a mutual
exclusion of source route and stateful routing.

But:
- I do not think that the means for source route and stateful routing
should necessary be the same. I can go into the gory details if people
follow me along that track. This has to do with when and why the methods
are being used (proactively or reactively). This also has to do with the
addresses involved (routing uses 1 hop link local, source route uses
global addresses. Which address would you use to source a DAO?). And
this has to do with the routing states being in place proactively so
they can be used to compress the record route when it comes.

 We've seen some strong concerns on the source route DAOs, in particular
recurring objections that we design as we go when we should be using
well-known techniques. The well-known technique for source route is LSRR
(in the data packets) and we have ample experience on it. Using it would
actually decouple the stateful DAO from the record route. More
importantly, that would allow the DAO states to compress a strict source
route into a loose one whenever possible, as already prescribed in RPL,
but probably not working so well since the routing states might be
populated too late.

I hope this helps...

Pascal

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jonathan Hui
> Sent: Tuesday, March 09, 2010 5:24 PM
> To: Tim Winter
> Cc: ROLL WG
> Subject: Re: [Roll] Establishing downward routes in RPL : storing
/non-storing
> To reiterate some of my messages in the past, I have been against
mixing of
> storing and non-storing nodes.  To indicate why, let me highlight some
of the
> issues.
keeping
> that state up-to-date, since only select nodes are storing such state.
> Specifically in RPL, it requires knowing which ancestor particular DAO
state is
> being maintained and sending DAO messages at appropriate times when
the
> ancestor changes.  In the fully storing case, the ancestor is simply
the parent
> and easy to detect.  In the fully non-storing case, the ancestor is
always the
> root, so again a node only needs to send updates if its immediate
parent
> changes.  In a mixed mode case, ideally the node would know which node
is
> storing its DAO information (it may not be the immediate parent or
even the
> first storing node) when that node changes.
> 
up
> with a good simple solution.  Early drafts specified that if a non-
storing node
> is triggered to send DAOs (e.g. due to a single link failure), it must
trigger
> DAOs from its descendants as well.  This can lead to O(N) messages due
to a
> single link failure.  The 'S' bit helped to optimized for the fully
non-storing
> case by indicating if there is a storing node that is not the root,
reducing to
> O(1) for a single link failure.  But doesn't help much in mixed-mode
> environments where the true worst-case is still O(N).
> 
MUST
> at least be able to operate in leaf mode, regardless of whether it
supports
> only storing or only non-storing.
> 
> --
> Jonathan Hui
> 
> > In the RPL-07 proposal the DAO mechanism described in Section 6
> > attempts to support operation with a mix of storing nodes and
> > non-storing nodes- where storing nodes may be provisioned with
enough
> > memory that they are capable to provision hop-by-hop downward routes
> > learned from DAO messages, and non-storing nodes would rely on
source
> > routing for downward routes.  The present proposal describes
operation
> > in a mixed mode operation, with both storing and non-storing nodes,
> > where each node may provision downward routing state as according to
> > its capabilities and largely independent of its position in the LLN
> > topology.
> >
> > root) are non-storing nodes allows for certain optimizations, and
that
> > the case where all nodes (except possibly leaves) are storing leads
to
> > other optimizations.  It has also been noted that in the mixed cases
> > the ability to provide an optimal solution may break down.  In
> > particular there are concerns about the complexity and correctness
of
> > mixed-mode operation as proposed by RPL-07.
> >
> > storing/non-storing nodes?  Or should each RPL Instance be
exclusively
> > operating in either storing or non-storing mode (with the provision
> > that operation as a leaf is always an option)?
> > (The non-mixed case may imply some control flag or equivalent given
in
> > the DIO to signal the mode of operation).
> >
> >
> > -Tim

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 09 Mar 2010 12:23:14 -0500

> Date: Tue, 9 Mar 2010 17:55:01 +0100
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 
> fully what makes it work or when.

Pascal,

The S bit reduces the DAO overhead in mostly non-caching
DODAGs.  This benefit, and thus the S bit, disappears if we
do not support mixed caching and non-caching DODAGs.  For
that reason, along with all the others that have been
mentioned, I am in favor of removing support for mixed
mode operation.

We have spent a good amount of effort trying to come up with
a workable solution and have not been successful.  For now
we should move on to other areas in need of attention, such
as P2P and multicast.
                                    -Richard

---

From: Anders Jagd <[email-masked]>
Date: Tue, 9 Mar 2010 17:12:33 -0500

Could someone please help me understand why there is such reluctance to
keeping a door open for mixed-mode operation ?

As I see it (but I may be missing something), the first few Object Functions
could certainly constrain the RPL Instance to either "all storing" or "no
storing"; other OFs potentially later to follow allowing for a mix.

What is it in the base document that becomes difficult to wrap-up while at
the same time allowing for this flexibility ? Would that "something" be
important enough to outweigh the potential cost of, after imposing such a
"no mix" restriction, later having to develop protocol translation gateways
between non-storing islands and storing backbone networks ?

/Anders

---

From: Matteo Paris <[email-masked]>
Date: Tue, 9 Mar 2010 17:58:51 -0500

Mixed mode is a much harder problem, for which we don't have a 
workable solution.  It also appears that it is not as common a use 
case.

Like others, I would like a cache-mode field in the DAG config 
suboption that specifies all-cache or only-root-cache.  These cases 
are relatively simple, so we can come to consensus on solutions for 
each quickly and move on to other pressing issues.  The cache-mode 
field could include a reserved value which could be used at some 
future date for specifying mixed-mode operation.

Matteo

At 5:12 PM -0500 3/9/10, Anders Jagd wrote:
>Could someone please help me understand why there is such reluctance 
>to keeping a door open for mixed-mode operation ?
>
>As I see it (but I may be missing something), the first few Object 
>Functions could certainly constrain the RPL Instance to either "all 
>storing" or "no storing"; other OFs potentially later to follow 
>allowing for a mix.
>
>What is it in the base document that becomes difficult to wrap-up 
>while at the same time allowing for this flexibility ? Would that 
>"something" be important enough to outweigh the potential cost of, 
>after imposing such a "no mix" restriction, later having to develop 
>protocol translation gateways between non-storing islands and 
>storing backbone networks ?
>
>/Anders
>
>On Tue, Mar 9, 2010 at 12:23 PM, Richard Kelsey 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>>  From: "Pascal Thubert (pthubert)" 
>><<mailto:[email-masked]>[email-masked]>
>
>  >
><mailto:[email-masked]>[email-masked]
><https://www.ietf.org/mailman/listinfo/roll>https://www.ietf.org/mailman/listinfo/roll
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Mar 2010 10:13:11 +0100

Hi Matteo and Anders :

There are known solutions to the mixed mode problem. Very, very well
known. That is called Loose Source and Record Route. But we did not use
that. We tried to merge the well know problem of the source route into
the DAO advertisement, and for such a merge I do not know of an
existing, working solution. And then we started proposing mechanisms
that opened more questions than they actually solved, and ultimately, we
lost confidence in what we were doing.

Obviously, this proposal to split seems to simplify, but since it does
not address the real problem, it does not provide the right solution,
and we end up throwing the baby with the bath water.

For me, the real answer to this call is to split the procedures used for
stateful and source route, as opposed to the deployment cases where
source route and stateful routing are used. 

That is, to leave the proactive DAO mechanism to stateful routing, and
use the classical data path LSRR for the source route. And those 2 work
great together, mostly independently. That way, stateful DAO happens
first and does not depend on source route, and then source route can
benefit from existing routing states to make the LSRR as small (loose)
as possible. It is up to a destination to advertise itself proactively
in the DAO system, or just on demand using source route.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Matteo Paris
Sent: Tuesday, March 09, 2010 11:59 PM
To: [email-masked]
Subject: Re: [Roll] Establishing downward routes in RPL : storing
/non-storing / mixed modes of operation

Mixed mode is a much harder problem, for which we don't have a workable
solution.  It also appears that it is not as common a use case. 

Like others, I would like a cache-mode field in the DAG config suboption
that specifies all-cache or only-root-cache.  These cases are relatively
simple, so we can come to consensus on solutions for each quickly and
move on to other pressing issues.  The cache-mode field could include a
reserved value which could be used at some future date for specifying
mixed-mode operation.

Matteo

	Could someone please help me understand why there is such
reluctance to keeping a door open for mixed-mode operation ?

	As I see it (but I may be missing something), the first few
Object Functions could certainly constrain the RPL Instance to either
"all storing" or "no storing"; other OFs potentially later to follow
allowing for a mix.

	What is it in the base document that becomes difficult to
wrap-up while at the same time allowing for this flexibility ? Would
that "something" be important enough to outweigh the potential cost of,
after imposing such a "no mix" restriction, later having to develop
protocol translation gateways between non-storing islands and storing
backbone networks ?

	/Anders

		Pascal,
		
		The S bit reduces the DAO overhead in mostly non-caching
		DODAGs.  This benefit, and thus the S bit, disappears if
we
		do not support mixed caching and non-caching DODAGs.
For
		that reason, along with all the others that have been
		mentioned, I am in favor of removing support for mixed
		mode operation.
		
		We have spent a good amount of effort trying to come up
with
		a workable solution and have not been successful.  For
now
		we should move on to other areas in need of attention,
such
		as P2P and multicast.
		                                   -Richard

---

From: "Roger Alexander" <[email-masked]>
Date: Wed, 10 Mar 2010 08:44:37 -0500

Hi Tim, WG,

I would be in favor of currently restricting RPL operation to storing and
non-storing modes only. Without entirely precluding the support for a mixed
mode in the future, the emphasis on storing and non-storing will allow for
greater clarity and focus of the specification effort. An early system
indication in the form of a control flag would be a good mechanism as it
would allow a mixed mode to be introduced in the future. 

Roger  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Winter
Sent: Tuesday, March 09, 2010 10:24 AM
To: ROLL WG
Subject: [Roll] Establishing downward routes in RPL : storing / non-storing
/ mixed modes of operation

WG,

-Tim

---

From: Anders Jagd <[email-masked]>
Date: Wed, 10 Mar 2010 13:22:25 -0500

Pascal, WG,

I think you are making a good case for data path LSRR *optionally*
supplemented by a stateful DAO mechanism, which would provide useful,
however not required, assistance in making the LSRR as loose as possible.

That said, I still haven't heard anyone explain the core problem with mixed
environments. Mixed working solutions not being known, or maybe being
difficult to test, doesn't seem to be quite enough reason for not
considering them. How could mixed working solutions really exist when the
problem we have been facing for so long, and which the WG has made great
progress towards resolving, is that we don't have the standards yet to allow
for heterogeneous multi-vendor systems.

If there is a fundamental problem with mixed environments (and I am not
saying there is not, I am just not aware of it - please educate me), then
fine, we can discuss if the problem is so severe that it will be too
costly/time-consuming to solve, but until then, I agree with Pascal that we
may be "throwing the baby out with the bath water". If the problem has been
analyzed previously, just point me towards the thread; I am not trying to
reopen an old discussion.

/Anders

On Wed, Mar 10, 2010 at 4:13 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hi Matteo and Anders :
>
>
>
> There are known solutions to the mixed mode problem. Very, very well known.
> That is called Loose Source and Record Route. But we did not use that. We
> tried to merge the well know problem of the source route into the DAO
> advertisement, and for such a merge I do not know of an existing, working
> solution. And then we started proposing mechanisms that opened more
> questions than they actually solved, and ultimately, we lost confidence in
> what we were doing.
>
>
>
> Obviously, this proposal to split seems to simplify, but since it does not
> address the real problem, it does not provide the right solution, and we end
> up throwing the baby with the bath water.
>
>
>
> stateful and source route, as opposed to the deployment cases where source
> route and stateful routing are used.
>
>
>
> That is, to leave the proactive DAO mechanism to stateful routing, and use
> the classical data path LSRR for the source route. And those 2 work great
> together, mostly independently. That way, stateful DAO happens first and
> does not depend on source route, and then source route can benefit from
> existing routing states to make the LSRR as small (loose) as possible. It is
> up to a destination to advertise itself proactively in the DAO system, or
> just on demand using source route.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Matteo Paris
> *Sent:* Tuesday, March 09, 2010 11:59 PM
> *To:* [email-masked]
>
> *Subject:* Re: [Roll] Establishing downward routes in RPL : storing
> simple, so we can come to consensus on solutions for each quickly and move
> on to other pressing issues.  The cache-mode field could include a reserved
> value which could be used at some future date for specifying mixed-mode
> operation.
>
>
>
> Matteo
>
>
>
>
>
> Functions could certainly constrain the RPL Instance to either "all storing"
> or "no storing"; other OFs potentially later to follow allowing for a mix.
>
>
>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 10 Mar 2010 10:57:49 -0800

Hi Anders,

On Mar 10, 2010, at 10:22 AM, Anders Jagd wrote:

> That said, I still haven't heard anyone explain the core problem  
> with mixed environments. Mixed working solutions not being known, or  
> maybe being difficult to test, doesn't seem to be quite enough  
> reason for not considering them. How could mixed working solutions  
> really exist when the problem we have been facing for so long, and  
> which the WG has made great progress towards resolving, is that we  
> don't have the standards yet to allow for heterogeneous multi-vendor  
> systems.

New standards are typically based on well-understood solutions.   
Anything else would be a research project and that has no place within  
the IETF.  The question that so many of us have raised is whether  
there are well-understood solutions for mixed-mode operation in the  
class of networks we are targeting.  At this point, it seems that  
there are not.

> If there is a fundamental problem with mixed environments (and I am  
> not saying there is not, I am just not aware of it - please educate  
> me), then fine, we can discuss if the problem is so severe that it  
> will be too costly/time-consuming to solve, but until then, I agree  
> with Pascal that we may be "throwing the baby out with the bath  
> water". If the problem has been analyzed previously, just point me  
> towards the thread; I am not trying to reopen an old discussion.

It's not that there is a fundamental problem with supporting mixed- 
mode operation.  It's that we have not yet found a satisfactory  
solution that supports mixed-mode environments effectively while at  
the same time not compromising the solutions that we care about today  
(fully stateless and fully stateful environments).  We have tried with  
one solution, but that has its issues that make many feel  
uncomfortable.  See previous mails in this thread for more details.

--
Jonathan Hui

---

From: [email-masked]
Date: Thu, 11 Mar 2010 08:27:45 -0600

Hi Tim,

With regard to your query regarding
all-or-nothing storing nodes in RPL; I agree it's too soon to make this
call.  Until the time we lock down exactly how P2P messaging will
be handled to meet the performance requirements, I think we must proceed
assuming a mixed network of storing and non-storing nodes.

Having packets traverse to/through the
LBR (non-storing mode) will not meet our latency requirement .  Yet
expecting every sensor to store routing info (storing mode) is not acceptable
from a constrained processor and memory perspective.  Once we know
how P2P works for intra-LLN packet communication, hopefully the non-storing
mode can be used for inter-LLN packet communication.  That would give
us the performance we need in the LLN yet have the connectivity needed
for communication to the outside world.

Jerry

From:

Anders Jagd <[email-masked]>

To:

Tim Winter <[email-masked]>

Cc:

ROLL WG <[email-masked]>

Date:

03/09/2010 10:18 AM

Subject:

Re: [Roll] Establishing downward routes
in RPL : storing /        non-storing / mixed
modes of operation

Tim,

I don't see that we would benefit from going as far as
generally dis-allowing a mix of storing/non-storing. Granted, most
networks would likely in practice be either storing on non-storing. However,
I am not convinced there would not be use cases justifying a mix.

Rather than tying our hands on this, would it not be better
to have each OF set rules/requirements for nodes to be "all storing",
"all non-storing", or "mix" ?

I actually don't think we are able to properly answer
questions like this properly before applicability work has been done -
which is the main reason I don't think we should go so far as to dis-allow
a mix quite yet.

/Anders

On Tue, Mar 9, 2010 at 10:23 AM, Tim Winter <[email-masked]>
wrote:

WG,

In the RPL-07 proposal the DAO mechanism described in Section 6 attempts
to support

downward routes learned from DAO messages, and non-storing nodes would
rely on source

routing for downward routes.  The present proposal describes operation
in a mixed

mode operation, with both storing and non-storing nodes, where each node
may

It has been noted that operation in the case where all nodes (except possibly
the

root) are non-storing nodes allows for certain optimizations, and that
the case where

may break down.  In particular there are concerns about the complexity
and

non-storing mode (with the provision that operation as a leaf is always
an option)?

(The non-mixed case may imply some control flag or equivalent given in
the DIO to

-Tim

Roll mailing list

[email-masked]

Roll mailing list

[email-masked]

---

From: "Pete St. Pierre" <[email-masked]>
Date: Thu, 11 Mar 2010 10:47:35 -0800

I strongly agree with Jerald's comments below.

On Mar 11, 2010, at 6:27 AM, [email-masked] wrote:

> 
> Hi Tim, 
> 
> With regard to your query regarding all-or-nothing storing nodes in RPL; I agree it's too soon to make this call.  Until the time we lock down exactly how P2P messaging will be handled to meet the performance requirements, I think we must proceed assuming a mixed network of storing and non-storing nodes.   

[forgive me if I'm missing something obvious, I've just tried to play catchup on this & other roll threads.]

I think we have to explicitly allow mixed-mode at this point, unless we determine that it is either not feasible or cannot meet the full set of requirements.  

If we begin to enforce two separate modes non-interoperable modes, it begins to feel to me like we have effectively created two non-interoperable protocols that just happen to look alike because of a shared header structure.  Since we're not chartered for two separate protocols, I think we need to reconcile the differences so they work together in an efficient manner.

...Pete

> 
> Having packets traverse to/through the LBR (non-storing mode) will not meet our latency requirement .  Yet expecting every sensor to store routing info (storing mode) is not acceptable from a constrained processor and memory perspective.  Once we know how P2P works for intra-LLN packet communication, hopefully the non-storing mode can be used for inter-LLN packet communication.  That would give us the performance we need in the LLN yet have the connectivity needed for communication to the outside world. 

> 
> Jerry
> 
> 
> 
> From:	Anders Jagd <[email-masked]>
> To:	Tim Winter <[email-masked]>
> Cc:	ROLL WG <[email-masked]>
> Date:	03/09/2010 10:18 AM
> Subject:	Re: [Roll] Establishing downward routes in RPL : storing /        non-storing / mixed modes of operation
> 
> 
> 
> 
> Tim, 
> 
> I don't see that we would benefit from going as far as generally dis-allowing a mix of storing/non-storing. Granted, most networks would likely in practice be either storing on non-storing. However, I am not convinced there would not be use cases justifying a mix. 
> 
> Rather than tying our hands on this, would it not be better to have each OF set rules/requirements for nodes to be "all storing", "all non-storing", or "mix" ? 
> 
> I actually don't think we are able to properly answer questions like this properly before applicability work has been done - which is the main reason I don't think we should go so far as to dis-allow a mix quite yet. 
> 
> /Anders
> 

--
Pete St. Pierre
[email-masked]
Sun Labs
Oracle 
16 Network Circle
Menlo Park, CA 94025

---

From: Philip Levis <[email-masked]>
Date: Sun, 14 Mar 2010 22:58:09 -0700

On Mar 10, 2010, at 10:57 AM, Jonathan Hui wrote:

>> That said, I still haven't heard anyone explain the core problem with mixed environments. Mixed working solutions not being known, or maybe being difficult to test, doesn't seem to be quite enough reason for not considering them. How could mixed working solutions really exist when the problem we have been facing for so long, and which the WG has made great progress towards resolving, is that we don't have the standards yet to allow for heterogeneous multi-vendor systems.
> 
> New standards are typically based on well-understood solutions.  Anything else would be a research project and that has no place within the IETF.  The question that so many of us have raised is whether there are well-understood solutions for mixed-mode operation in the class of networks we are targeting.  At this point, it seems that there are not.
> 
>> If there is a fundamental problem with mixed environments (and I am not saying there is not, I am just not aware of it - please educate me), then fine, we can discuss if the problem is so severe that it will be too costly/time-consuming to solve, but until then, I agree with Pascal that we may be "throwing the baby out with the bath water". If the problem has been analyzed previously, just point me towards the thread; I am not trying to reopen an old discussion.
> 
> 
> It's not that there is a fundamental problem with supporting mixed-mode operation.  It's that we have not yet found a satisfactory solution that supports mixed-mode environments effectively while at the same time not compromising the solutions that we care about today (fully stateless and fully stateful environments).  We have tried with one solution, but that has its issues that make many feel uncomfortable.  See previous mails in this thread for more details.
> 
> --
> Jonathan Hui

+1

Phil