Re: [PATCH 1/2] mesh: Add sequence nr getter to the doc

["Gix, Brian" <brian.gix@intel.com>]

Hi Michał & Jakub,

On Tue, 2020-01-14 at 16:40 +0100, Michał Lowas-Rzechonek wrote:
> Hi Brian,
> 
> On 01/14, Gix, Brian wrote:
> > > +	uint32 SequenceNumber [read-only]
> > > +
> > > +		This property may be read at any time to determine the
> > > +		sequence number.
> > > +
> > 
> > Is there a use case justification for exposing this value?  Why an Application would need this?
> 
> There are 2 use cases:
>  - debugging and monitoring RPL behaviour

I need to think about this a bit and discuss with Inga

>  - we'd like to add another API to increase the sequence number - this
>    is useful when you Import() a node from another database and would
>    like to bump its sequence number up to a previously known value, so
>    that the rest of the network can talk to it

I have some serious discomfort with an API to increase sequence numbers.  On import,
the sequence number should be part of the data being imported, so I don't see a
direct need there to bump up the value afterwards.

Plus, we handle sequence numbers differently than many other settings in the
system.  To prevent storage thrashing, we "Pre-Reserve" a chunk of sequence
numbers that we store in node.json, and then real-time use these sequence
numbers for outbound packets without having to write to storage each time
(a power failure or other reset would then pick up after the reserved chunk).
And then it also feeds into the IV Index update feature as well.

Giving an App the ability to arbitrarily increase it's sequence number puts
it into conflict with the natural usage of sequence numbers, and when we request
the IV Index Update.