Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: JeongGil Ko <jeonggil.ko@gmail.com>
In-Reply-To: <6A41B5D8-316A-4958-9259-AD37DD5DE9DC@cisco.com>
Date: Tue, 23 Oct 2012 15:32:17 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <A67B4938-A792-4E8B-BCB1-AFFC0BD8A452@gmail.com>
References: <CAErDfUQV2E5H66k9YjRSGF8RmA=xhQzrDwpyTRBJ8WQUZh3diw@mail.gmail.com>
 <B7828579-4864-4CBA-A999-808F394D543F@cisco.com>
 <BD04C41F-0368-4AEB-8E23-EA3043298599@etri.re.kr>
 <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com>
 <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu>
 <CADnDZ8_zVK=ueFQ9BRA2SQggUkrC32_Qvi0RTSmV4d4puwQVCg@mail.gmail.com>
 <A48E3E6B-C1BC-4D94-84FB-126992B70990@cs.stanford.edu>
 <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr>
 <10F4D589-F3F6-400D-9F34-B93FDC2E5A42@cs.stanford.edu>
 <1BACA0A8-CF05-418E-9C5E-657FB0713037@etri.re.kr>
 <6A41B5D8-316A-4958-9259-AD37DD5DE9DC@cisco.com>
To: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>,
 Philip Levis <pal@cs.stanford.edu>
Cc: JeongGil Ko <jeonggil.ko@etri.re.kr>, roll WG <roll@ietf.org>
Subject: Re: [Roll] mixture of storing and non-storing nodes
Precedence: list

JP, Phil,

I've updated the draft with additional use cases and my previous email =
on the list regarding the draft update should provide an answer to the =
questions that came up on this email thread :)

Thanks!

-John


On Sep 5, 2012, at 8:08 PM, JP Vasseur (jvasseur) <jvasseur@cisco.com> =
wrote:

> 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.
>=20
> JP.
>=20
> On Sep 5, 2012, at 3:34 AM, JeongGil Ko wrote:
>=20
>> Phil,
>>=20
>> 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.
>>=20
>> Thanks!
>>=20
>> -John
>>=20
>>=20
>> On Sep 5, 2012, at 10:29 AM, Philip Levis wrote:
>>=20
>>> 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.
>>>=20
>>> Phi
>>>=20
>>> On Sep 4, 2012, at 5:36 PM, JeongGil Ko wrote:
>>>=20
>>>> Phil,
>>>>=20
>>>> 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).
>>>>=20
>>>> 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.
>>>>=20
>>>> 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 mi
> x
>>=20
>>> 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.
>>>>=20
>>>> 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 :)
>>>>=20
>>>> Thanks!
>>>>=20
>>>> -John
>>>>=20
>>>>=20
>>>> On Sep 5, 2012, at 1:17 AM, Philip Levis wrote:
>>>>=20
>>>>>=20
>>>>> On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote:
>>>>>=20
>>>>>> Hi Philip,
>>>>>>=20
>>>>>> 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.
>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> Roll@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>=20
>>>=20
>>>=20
>>> Phil
>>>=20
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>>=20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll