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

From: Philip Levis <[email-masked]>
Date: Mon, 3 Sep 2012 14:36:37 -0700

On Aug 23, 2012, at 10:06 PM, JP Vasseur (jvasseur) wrote:

>  Thanks for your feed-back, great discussion. If we have sufficient requirements for such a case (let's see what the WG says)

It seems like so far no one has presented a strong case; I'd argue that we should table it until it's needed. RPL is complicated enough already.

Phil

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Sep 2012 12:04:33 +0200

Hi Philip,

I also think that RPL is complicated, for good reasons, but not always
complicated protocols should not be optimized or assisted by others.
However, new ideas and drafts are always recommended.

AB

On 9/3/12, Philip Levis <[email-masked]> wrote:
>>  Thanks for your feed-back, great discussion. If we have sufficient
>> requirements for such a case (let's see what the WG says)
>
> It seems like so far no one has presented a strong case; I'd argue that we
> should table it until it's needed. RPL is complicated enough already.
>
> Phil
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Philip Levis <[email-masked]>
Date: Tue, 4 Sep 2012 09:17:49 -0700

> However, new ideas and drafts are always recommended.

As an academic, I agree wholeheartedly. Also as an academic, I'd argue that new ideas which do not have a strong application pull are the province of research, not standardization. Our goal here is to standardize practice for interoperability, not come up with new ideas. But that's just my 2 cents.

Phil

---

From: JeongGil Ko <[email-masked]>
Date: Wed, 5 Sep 2012 09:36:29 +0900

Phil,

With the RFC 6550, developers can build applications with storing mode or not-storing mode nodes. In some cases they 'can' design systems to be mixed, but since either one of the modes should act as a leaf node, they may result in forming non-optimal routes (in both traffic directions).

While it may not be a general application (I think it can be but others may think differently), we are currently designing a system where (relatively) resource-rich nodes act as sub-DODAG heads (I am using this expression due to the lack of a better term) and a larger number of resource-constraint nodes act as sensing units. Basically it's a network with device heterogeneity and the two devices have their respective tasks in the network. This doesn't necessarily mean that these resource constraint nodes are always positioned physically at a corner of the network to act as leaf nodes. The physical location of any of these nodes can be at locations where by using it to forward packets, can increase the efficiency of packet forwarding on the DODAG. Thus, but forcing a set of nodes to be leaf nodes, we may miss a chance to have more efficient routing paths.

In such a network, given RFC 6550, to make sure that the default route performs at its optimal, a system designer needs to select between the storing or non-storing mode (this is the only way we can have all the nodes in the network capable of forwarding packets). First, since we have memory constraints, we do not want the resource constraint nodes to implement storing mode; thus, a full storing mode network is not an option. On the other hand, implementing the entire network with non-storing mode would be inefficient since packets would always have to travel to the DODAG root for all downwards packets (not saying its not going to work but less efficient). An alternative would be to implement non-storing mode for nodes that cannot meet the heavier memory requirements and for the nodes that can spare some space to store routes... use the storing mode. This can help cut the stretch of the packets that travel to non-root destinations. Networks with device heterogeneity (a mix of powerful and 'dumb' nodes) can choose to use such 'mixed' network configuration to preserve the upwards routing performance and also perform downwards routing efficiently. The draft  simply proposes a few light weight changes that are required to make this happen.

I agree with you that if a proposal not realist nor useful in real life, that it is meaningless (or less meaningful) to push the proposal on the standards track. Nevertheless, I believe that we should make sure that RPL can allow/tolerate for various network configurations so that it is not the standards that is limiting the development of new systems. My $0.02 :)

Thanks!

-John

---

From: Philip Levis <[email-masked]>
Date: Tue, 4 Sep 2012 18:29:05 -0700

In that case, you're the application that is the compelling use case. eIt would be great if you could write a document that more concretely lays out your arguments below; they seem sound to me, but one short email seems insufficient to motivate a significant protocol addition. A more detailed design document would also clearly specify the constraints of the solution. For example, from your description below, it sounds like complete mixed mode is unnecessary; instead, allowing non-storing trees off of a storing network would be sufficient. It could be that setup covers 99% of the mixed use cases, and it is much much simpler than arbitrary compositions.

Phi

Phil

---

From: JeongGil Ko <[email-masked]>
Date: Wed, 5 Sep 2012 10:34:21 +0900

Phil,

Thanks for your feedback. Nice idea with the additional informative documentation. I will get together with the authors of the draft to discuss and initiate an informative document.

Thanks!

-John

On Sep 5, 2012, at 10:29 AM, Philip Levis wrote:

>> In such a network, given RFC 6550, to make sure that the default route performs at its optimal, a system designer needs to select between the storing or non-storing mode (this is the only way we can have all the nodes in the network capable of forwarding packets). First, since we have memory constraints, we do not want the resource constraint nodes to implement storing mode; thus, a full storing mode network is not an option. On the other hand, implementing the entire network with non-storing mode would be inefficient since packets would always have to travel to the DODAG root for all downwards packets (not saying its not going to work but less efficient). An alternative would be to implement non-storing mode for nodes that cannot meet the heavier memory requirements and for the nodes that can spare some space to store routes... use the storing mode. This can help cut the stretch of the packets that travel to non-root destinations. Networks with device heterogeneity (a mix 
> of powerful and 'dumb' nodes) can choose to use such 'mixed' network configuration to preserve the upwards routing performance and also perform downwards routing efficiently. The draft  simply proposes a few light weight changes that are required to make this happen.
>>

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Wed, 5 Sep 2012 11:08:36 +0000

Fully agreeing with Phil; as RPL is being deployed and mature, we need to be careful not to add anything that is not strongly
motivated by a concrete use case and requirements. Thanks for your work.

JP.

---

From: JeongGil Ko <[email-masked]>
Date: Wed, 5 Sep 2012 20:23:30 +0900

JP,

Thanks for your feedback as well! As a RPL implementer, I too fully agree that RPL should not get any more complex for a random reason. I just wanted to introduce a case where there was definitely an issue with performance inefficiency and proposed a potential solution to the issue. As said in an earlier email, I think its fair to say that an additional document stating the use case and system level requirements can help convince others of the issue that we address with the work.

Thanks! :)

-John

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 9 Sep 2012 23:55:48 +0200

On 9/4/12, Philip Levis <[email-masked]> wrote:
> As an academic, I agree wholeheartedly. Also as an academic, I'd argue that
> new ideas which do not have a strong application pull are the province of
> research, not standardization. Our goal here is to standardize practice for
> interoperability, not come up with new ideas. But that's just my 2 cents.
>

I disagree that we only "standardize practice for interoperability",
but we also standard to solve problems that face LLNs and RPL, by new
ideas/protocols. For example, RPL is an IETF standard but still not
fully in practice, yet was a good idea to standard. Furthermore, there
are many deployment results not shown in IETF, but used by researchers
or companies elsewhere. I am working on a new protocol to be standard
by IETF because it will solve an important LLN routing problem.

AB