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

[Hudson Randal Ayers <[e-mail]>]

Hi Anand,

Thanks for your thoughtful questions! My replies are inline.

Best,
Hudson

________________________________
From: 6lo <[e-mail]> on behalf of S.V.R.Anand <anandsvr=[e-mail]>
Sent: Tuesday, July 28, 2020 7:45 AM
To: Hudson Randal Ayers <[e-mail]>
Cc: [e-mail] <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lo