Hi Anand, Thanks for your thoughtful questions! My replies are inline.
Best, Hudson ________________________________ From: 6lo <[email protected]> on behalf of S.V.R.Anand <[email protected]> Sent: Tuesday, July 28, 2020 7:45 AM To: Hudson Randal Ayers <[email protected]> Cc: [email protected] <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
