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

[Philip Levis <[e-mail]>]

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

On Sep 4, 2012, at 5:36 PM, JeongGil Ko wrote:

> 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
> 
> 
> On Sep 5, 2012, at 1:17 AM, Philip Levis wrote:
> 
>> 
>> On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote:
>> 
>>> 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.
>> 
>> 
>> 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
>> 
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
> 


Phil