Re: [6lo] Update to draft-ayers-low-power-interop-01

"S.V.R.Anand" <anandsvr@iisc.ac.in> Wed, 29 July 2020 09:16 UTC

Return-Path: <anandsvr@iisc.ac.in>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E7A3A0B55 for <6lo@ietfa.amsl.com>; Wed, 29 Jul 2020 02:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iisc.ac.in
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7RQIRBvOapt for <6lo@ietfa.amsl.com>; Wed, 29 Jul 2020 02:16:00 -0700 (PDT)
Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-eopbgr1380057.outbound.protection.outlook.com [40.107.138.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3A53A0AD4 for <6lo@ietf.org>; Wed, 29 Jul 2020 02:15:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QH4PSFTRgWJeO6SAhHQbkDc1lsiarr+2SLdMo97ccFnsU01JCfPmf4SROqTd64j1nUYVVq3HoEfnwevFLKTE40f6dpX6tO/sv2abRA2SpnuUY+wfq1DE2aVacysyHkwmc1tPp6FtHsJD2o8iO7wLfD8f4hK7QvGpQCuTu2pKjyKYkSOPDjWCNMth30NJis92R8w5KxGRwmBzhAuAo3bBGl3NFo8vmDHgUVa9hrRpQxIgR+gfsXAnzChBToupQIEXIoNc3hdAMYV/Wv/sTyArucCbDn/dZda3huqK3aDMy9ByR/o0wrf22wUG8/nU33O9rYDvhq0lGL+IvWv0QXqJAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BHIPLOEgJA4pUAl9j6MZ/sPwwDQbJDkFpvBI13l0DBQ=; b=oJInFVZ4oXE78I1WWKBv5KBFu+m6A3supzWrjuF4U2CZ20I2GUyhDWOJ+lTU1vG3pF5QeWwxrbQO1I4fcF+oB5JytOovcDWlt67KN6xwLEgwayViNoO4eBwmyEkedWh9Yd0kpzErWNqLrltZ4TrVyqYwjZVByAKiDEiCFr2gt2X5D1PMIUnXWqO3rm8N74c9G5mL6Krpw5yQU9qhPty3oSu/1yYoPXrVf8Q87TaYsknYDFZSye+zq3oqq55vi6SstHGY1g9bveGYkIL7I73PeLTW0Fjp9y2GuiFxM7WDtdeiw7N/fir7e85rx7W0gh4aKxNOn1Xf4HdlCP1SUJk9kA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BHIPLOEgJA4pUAl9j6MZ/sPwwDQbJDkFpvBI13l0DBQ=; b=mxE5+CSWiZUfpfHmoQjQR4AJhkQnx8hBh24lyFyr5cMRYz0eSy+U2FfVWaqmsf7SjjcLfGulKeJIxspMMMmE0Cc8mLDqXpaCV76VSnLEUE0aMlA59cjSVTanOMAWgIqjlgrJ89DxUbgrV+V4sdsZMW6aKesr1rhHB114pGShDSE=
Authentication-Results: stanford.edu; dkim=none (message not signed) header.d=none;stanford.edu; dmarc=none action=none header.from=iisc.ac.in;
Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MA1PR01MB3546.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:72::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul 2020 09:15:55 +0000
Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::4c39:72dd:785a:4536]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::4c39:72dd:785a:4536%7]) with mapi id 15.20.3239.016; Wed, 29 Jul 2020 09:15:55 +0000
Date: Wed, 29 Jul 2020 14:45:54 +0530
From: "S.V.R.Anand" <anandsvr@iisc.ac.in>
To: Hudson Randal Ayers <hayers@stanford.edu>
Cc: "6lo@ietf.org" <6lo@ietf.org>
Message-ID: <20200729091550.GB4898@iisc.ac.in>
References: <BYAPR02MB542945EDDE2ABB726E85A5BAA3720@BYAPR02MB5429.namprd02.prod.outlook.com> <20200728144530.GA3178@iisc.ac.in> <BYAPR02MB54297179B56AAB82D983269AA3730@BYAPR02MB5429.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BYAPR02MB54297179B56AAB82D983269AA3730@BYAPR02MB5429.namprd02.prod.outlook.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-ClientProxiedBy: MAXPR0101CA0070.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:e::32) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from iisc.ac.in (49.206.11.53) by MAXPR0101CA0070.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Wed, 29 Jul 2020 09:15:55 +0000
X-Originating-IP: [49.206.11.53]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e16c4ecc-c9f6-4711-fbf1-08d8339fffa7
X-MS-TrafficTypeDiagnostic: MA1PR01MB3546:
X-Microsoft-Antispam-PRVS: <MA1PR01MB354648274AAAC41A3E228AACFC700@MA1PR01MB3546.INDPRD01.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 8DftOrWeVlC2ySjsMXTEG7M5uBj2jSSHcqlDnjbhJoMzC7cApctuYMEURrScV6shFH7Jd5L1e8zdnrEkDS9RxtEnJ2nmMs0r/gw69SEfqoafgiwtpco1qSDrDnFqDgyMbTa0UFqb/oITz2mYz5B0f9racU/VVGtpqLpylX7m6IdBvXL5hwwIya2XyVcHxY7iLDU4hW9XJsHYDi/bGhrfZHCxc0lyn96cXQaTOWYNPb+yUy/kybEzV8Z4T4tKfNvh9L2EgdR6q/rYttId+nEM+HiIBNRjzYm0yHaj+teMpJ7OHM9kYpE9XWAAB1Lt8vAmbcDGXfZXgoXl1Phi7Eyndl83XeIpdra48JDkMMu+qVBT7jV97vKVMUkcQXzCbOneblXLfWe0hSyVrypKrXELvg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(346002)(39860400002)(396003)(136003)(4326008)(966005)(55236004)(83380400001)(26005)(36756003)(52116002)(186003)(16526019)(66476007)(8676002)(15650500001)(478600001)(7696005)(86362001)(6916009)(53546011)(66556008)(1006002)(2906002)(33656002)(1076003)(8936002)(2616005)(5660300002)(316002)(55016002)(786003)(956004)(66574015)(66946007); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: /nn8wCnXHNiHNMfW42wQZam7m1gJGiFcz0CZ/v6aVx1d3jKlP4u24vGvdxh8aQHFZsaXWK2M2yUyR9pQTlugYo3KZLRe7YYvq6AGgewM/+4jLA6URKP4y7hdhw+HWoVys9UMQfklfJLCeUyov5kCLKM5F4jx1HcEmXwqORm2PAWQQ7jKs87TLz4j94zAY0n9FcapULXjXduMgBH3bANo921QS9pFxq/A8xLq9jvtjdUDSmsauBAAgBjPFi068nGZWrjrdGZWmMqzgoimwI7cp+ajSrteiGaP2RwIYRehMysKcs+a4FXMFr/vzABAWBxviMdYBW3R5powRFAX2ibhfiGPp9BahXW94rIr1fsIqXRYMIRx4FbL5TVfVHHITfnEscHupe6XA1pWBMCwK56xnlOrs/6sQ24FKmbFOIqs004LZn72NNjyKFv/ex42QoFRHsnbVjJ0qEzX8RrVeAf+LLywbtorK8JHSd/Xizs3tGo=
X-OriginatorOrg: iisc.ac.in
X-MS-Exchange-CrossTenant-Network-Message-Id: e16c4ecc-c9f6-4711-fbf1-08d8339fffa7
X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2020 09:15:55.6719 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TO/S5C0DoKDRK8anx8DZkw8I6EPlYBKLpK6HHCEQFfvi3w3hyy+Q7RKbQTFAswru6LouezJR6zUSKunN6LCxaw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR01MB3546
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/0r8NK1-ZljaXFShhHogfro0dSmA>
Subject: Re: [6lo] Update to draft-ayers-low-power-interop-01
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 09:16:03 -0000

Hi Hudson,

Thanks for your detailed reply! Just few additional thoughts.

The key point you are making is about market forces pushing for lean
kernels in spite of increase in the flash size. Like the rest of the
document where lot of data has been provided to quantify the benefit
gained in memory, it might be useful to substantiate your view by

  - Giving few examples in Figure 1, where flash size is small in the
    contemporary IoT platforms. As it stands after seeing Figure 1, 
    one gets the impression that present and future look bright, 
    where is the problem ? :)
  - Quantifying the share of the network stack for level 5 implementation in
    relationship with the rest of the kernel for various flash sizes.

Other artifacts I mentioned are more from the holistic point of view.
The way RPL routes are chosen could potentially depend on the level of
the compression, which in turn could impact network performance and
lifetime in some way or the other. It is possible that the RPL might end
up choosing the paths with nodes that implement level 5 since that offers
better PDRs, lesser delays for a given BER, and power savings.

Regards
Anand


On Tue, Jul 28, 2020 at 07:30:50PM +0000, Hudson Randal Ayers wrote:
> 
> Hi Anand,
> 
> Thanks for your thoughtful questions! My replies are inline.
> 
> Best,
> Hudson
> 
> ________________________________
> From: 6lo <6lo-bounces@ietf.org> on behalf of S.V.R.Anand <anandsvr=40iisc.ac.in@dmarc.ietf..org>
> Sent: Tuesday, July 28, 2020 7:45 AM
> To: Hudson Randal Ayers <hayers@stanford.edu>
> Cc: 6lo@ietf.org <6lo@ietf.org>
> Subject: Re: [6lo] Update to draft-ayers-low-power-interop-01
> 
> Hi Hudson Ayers,
> 
> I went through the draft and found it very interesting. There are few
> points I would like to mention.
> 
> - The figure 1 clearly indicates that the flash size is increasing all
> the time. This could be due to the increase in the application demands.
> Given that the network stack size is not going to change, even for level
> 5, don't you think its percentage of share continues to reduce with ever
> increasing flash size ?
> 
> While there has been a general trend of flash size increasing with time, it is still the
> the case that lower cost boards are those with less flash. Also, the trend toward more
> integrated system-on-chip platforms means that most newer platforms
> with additional flash available also have additional on-chip peripherals that require
> support in software. This means that the additional space actually available to applications
> running on an OS kernel often remains small. Also, even with some decrease in the share of total
> flash consumed by the networking stack, market forces often push users of embedded OSes towards
> more minimal kernels, and this pushes embedded OSes to strive for minimal code size whenever possible.
> 
> - While the draft primarily focuses on the interoperability we may have
> to consider certain artifacts that could play out. For instance, how
> multicast can possibly be handled ? Would the node use lowest level
> among its neighbours ? or all nodes use the level 0 in general ?
> 
> It depends on the link-layer mechanism used. For link-layer broadcasts,
> a node would use the lowest level among its neighbours,
> as a routing node would know the capability levels of its neighbours.
> However my understanding is that 6LoWPAN allows for the use of multiple unicast
> link layer messages to forward IPv6 multicast packets, in this case each node
> receiving a unicast message would be sent a message compressed to its respective
> capability level.
> 
> - From the perspective of RPL OF, it would be good to mention what one
> can expect if we have intermediate nodes supporting different levels of
> implementation, meaning different packet sizes in the air.
> 
> This is an interesting side effect which I had not considered. I think that most
> nodes configured to support routing would be the highest level -- my experience analyzing
> open source implementations and uses of 6LoWPAN is that those that skimp the
> most on features are nodes used primarly as edge nodes only. So one option is to
> require routing capable nodes to support the highest capability.
> I am not super familiar with the details of RPL and how the OF is calculated, but I
> imagine the next best alternative would involve some multiplication of the link throughput
> based on the capabilities of the nodes involved.
> 
> Regards
> Anand
> 
> 
> 
> On Mon, Jul 27, 2020 at 12:12:18AM +0000, Hudson Randal Ayers wrote:
> > External Email
> >
> > Hi all,
> >
> > I recently published an update to my Internet draft titled "Design Considerations for Low Power Internet Protocols". It is an informational draft which uses 6LoWPAN as a case study to dissect difficulties achieving interoperability for implementations of low power Internet protocols. I first published this draft two years ago, and originally presented it at the 6LoWPAN working group meeting at IETF 103. I have made a number of updates to this work since then which I think may be of interest to the group, and am presenting these updates at the 6LoWPAN working group meeting at IETF 108 this week.
> >
> > A link to the draft can be found here if you are interested! https://tools.ietf.org/html/draft-ayers-low-power-interop-01
> >
> > Any feedback is appreciated, as is any discussion at the working group meeting on Wednesday.
> >
> > Thanks,
> >
> > Hudson Ayers
> 
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf..org/mailman/listinfo/6lo<https://www.ietf.org/mailman/listinfo/6lo>
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo