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

"JP Vasseur (jvasseur)" <jvasseur@cisco.com> Fri, 24 August 2012 05:06 UTC

Return-Path: <jvasseur@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDABF21F854D for <roll@ietfa.amsl.com>; Thu, 23 Aug 2012 22:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id citwwC8I0CuK for <roll@ietfa.amsl.com>; Thu, 23 Aug 2012 22:06:17 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA421F854B for <roll@ietf.org>; Thu, 23 Aug 2012 22:06:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3708; q=dns/txt; s=iport; t=1345784777; x=1346994377; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rQsCpH/4DRRXpI8ve0u6k322HgXJB+IObotniWXBV+8=; b=A0zSrdkydVhjuLFa8/iFWnnF3S9kP++uzy6wfZnxD80ECBAyQh1zFbJF 1zZZ/5agR5MlkfzN869lXYR5OhYLbmL2as+TWZdGzO+N/EyLC6X506Zcp C1NfCXOqKkl/izmZHJBzCqfiQ0x13eovnGmvy6NBTizm3OTefPfBRp1gl Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIkKN1CtJXHB/2dsb2JhbABFulKBB4IgAQEBAwEBAQEPASc0CwULAgEIGB4QJwslAgQOBRsHh2UGC5k+oCGLCBqGF2ADlVSBFI0ZgWeCY4Fh
X-IronPort-AV: E=Sophos;i="4.80,302,1344211200"; d="scan'208";a="111820211"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 24 Aug 2012 05:06:16 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7O56Eqm010889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Aug 2012 05:06:14 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.209]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 24 Aug 2012 00:06:14 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: JeongGil Ko <jeonggil.ko@etri.re.kr>
Thread-Topic: [Roll] mixture of storing and non-storing nodes
Thread-Index: AQHNgC14aerYJYORe0Sa2/SEM2k1rg==
Date: Fri, 24 Aug 2012 05:06:14 +0000
Message-ID: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com>
References: <CAErDfUQV2E5H66k9YjRSGF8RmA=xhQzrDwpyTRBJ8WQUZh3diw@mail.gmail.com> <B7828579-4864-4CBA-A999-808F394D543F@cisco.com> <BD04C41F-0368-4AEB-8E23-EA3043298599@etri.re.kr>
In-Reply-To: <BD04C41F-0368-4AEB-8E23-EA3043298599@etri.re.kr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.60.114.232]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.004
x-tm-as-result: No--47.977800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8EAF607596456E4CBAC8575B10AFD524@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: roll WG <roll@ietf.org>
Subject: Re: [Roll] mixture of storing and non-storing nodes
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2012 05:06:24 -0000

Hi,

On Aug 22, 2012, at 4:35 PM, JeongGil Ko wrote:

> JP,
> 
> Thanks for your input! I fully agree that the added complexity should be minimal. We have a poster at this year's SenSys indicating that the overhead of supporting the 'mixed' mode only requires minimal additional complexity. One of the design goals in designing the scheme was to minimize the additional overhead on non-route storing devices since, in most cases, these are the devices that will actually operate with strict memory/complexity requirements. Nevertheless the additional memory required to implement the scheme for both types of devices, storing and non-storing, (which we've done experimentally with TinyOS and NanoQplus implementations) is minimal.
> 
> To think about it, things get more complicated if we try to define an entirely new mode for hybrid operations, but, storing mode and non-storing mode both have their own benefits. Since the draft talks about a case where we can still preserve the nature of the two modes AND allow them to interoperate, I believe that this is a meaningful draft for the WG.

Many Thanks for your feed-back, great discussion. If we have sufficient requirements for such a case (let's see what the WG says)
and minimal changes required to meet the requirements, why not, but I just wanted to raise the concern.

Thanks.

JP.

> 
> Thanks!
> 
> -John
> 
> ------
> JeongGil Ko, Ph.D.
> Researcher
> Electronics and Telecommunications Research Institute (ETRI)
> http://sites.google.com/site/jeonggilko/
> 
> On Aug 22, 2012, at 3:15 PM, JP Vasseur (jvasseur) wrote:
> 
>> Hi,
>> 
>> On Aug 21, 2012, at 6:31 PM, Omprakash Gnawali wrote:
>> 
>>> Dear ROLL WG,
>>> 
>>> John Ko posted a draft a few days ago about how we might accommodate a
>>> mixture of storing and non-storing nodes in a network more efficiently
>>> than making one of them leaf nodes. Searching through the ROLL mail
>>> archives, it was clear at the time that there was no use case for
>>> having a network that has a mixture of storing and non-storing nodes.
>>> I wonder if this is necessarily true if there are devices from
>>> multiple vendors. At the time, it was also speculated that the mixture
>>> could also introduce unknown problems and no one seems to have a
>>> working solution. The draft describes one of the problems that could
>>> occur if we try to form a multi-hop network with storing and
>>> non-storing nodes. That is a concrete first step towards getting a
>>> handle on the challenge of having nodes with different capabilities in
>>> a network.
>>> 
>>> Your guidance on whether this is an important problem worth working on
>>> or the work is heading in a wrong direction would help evolve or stop
>>> the work.
>>> 
>> 
>> JP> I cannot agree more - actually we even have a partial to the problem during the initial design phase and
>> the WG collectively decided not to mix storing and non-storing in light of the added complexity. I would also
>> appreciate the feedback of the WG on this, and not add complexity unless this becomes a strong requirement.
>> 
>> Thanks.
>> 
>> JP.
>> 
>>> Thanks.
>>> 
>>> - om_p
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll