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

From: Hudson Randal Ayers <[email-masked]>
Date: Mon, 27 Jul 2020 00:12:18 +0000

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

---

From: "S.V.R.Anand" <[email-masked]>
Date: Tue, 28 Jul 2020 20:15:33 +0530

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 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 ?

- 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.

Regards
Anand

On Mon, Jul 27, 2020 at 12:12:18AM +0000, Hudson Randal Ayers wrote:
> External Email

> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Hudson Randal Ayers <[email-masked]>
Date: Tue, 28 Jul 2020 19:30:50 +0000

Hi Anand,

Thanks for your thoughtful questions! My replies are inline.

Best,
Hudson

________________________________
From: 6lo <[email-masked]> on behalf of S.V.R.Anand <anandsvr=[email-masked]>
Sent: Tuesday, July 28, 2020 7:45 AM
To: Hudson Randal Ayers <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [6lo] Update to draft-ayers-low-power-interop-01

Hi Hudson Ayers,

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.

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.

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

---

From: "S.V.R.Anand" <[email-masked]>
Date: Wed, 29 Jul 2020 14:45:54 +0530

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:
> From: 6lo <[email-masked]> on behalf of S.V.R.Anand <anandsvr=[email-masked]..org>
> > https://www.ietf..org/mailman/listinfo/6lo<https://www.ietf.org/mailman/listinfo/6lo>
>

---

From: Hudson Randal Ayers <[email-masked]>
Date: Fri, 31 Jul 2020 20:47:29 +0000

Hi,

I agree that better quantifying the size of the network stack relative to other kernel components would be useful, I will see if we can do that for future drafts.

Agreed that thinking of the impacts of these changes from a holistic perspective is important! That would be an interesting evaluation to consider.

Best,
Hudson
________________________________
From: S.V.R.Anand <[email-masked]>
Sent: Wednesday, July 29, 2020 2:15 AM
To: Hudson Randal Ayers <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [6lo] Update to draft-ayers-low-power-interop-01

Hi Hudson,

Regards
Anand