Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling

Hello Michael 

The default of 16 points in the straight line is there to cover multiple losses in a row; 16 may be too large for a reliable Mac like TSCH in which case a node may start at another value, e.g., 250. Starting at 255 looks optimistic though. In case of a loss numbers will move to the circular part and will be uncomparable.

It is not really that the node is stable that counts but that all other nodes got a chance to see that this node as rebooted so they can reset their reference value and keep numbers comparable.

I’m happy to pursue this discussion to see more clearly than I do now; at this point I still do not see what change we could make - and why - to the sequence counter behavior...

Take care,

Pascal

> Le 12 mai 2018 à 20:58, Michael Richardson <mcr+ietf@sandelman.ca> a écrit :
> 
> 
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>    mcr> So I think that the errata against 6550 is that it should be a lollipop
>    mcr> counter, and I think that this solves the reboot problem, and eliminates
>    mcr> having to write it to flash.
> 
>    rj> [RJ] this still does not solve the reboot issue... The text in the
>    rj> draft actually considers dtsn to be a lollipop counter and explains
>    rj> the problem when rebooting within the sequence window of lollipop
>    rj> counter. Please refer to section 7.2 of the draft for example. Errata
>    rj> is nonetheless needed for dtsn to be a lollipop counter.
> 
>    pt> Well, yes, but that’s true for any of the sequence counters, not just
>    pt> DTSN, and was not perceived as an “issue”. 
>    pt> The lollipop by design detects one reboot during the straight
>    pt> part. More will cause a delay. There are ways to avoid that like
>    pt> persistent memory or alleviate it like making the straight part
>    pt> shorted on reliable links.  I’m not sure there’s much to add to that
>    pt> or to fix, is there?
> 
> Pascal, I feel that Rahul has some point that we've missed.
> 
>>  behalf of node A).  As per section 7.2. of [RFC6550], when node B
>>  receives this packet it will consider the information to be old
>>  (since 240 < 250).
> 
>>  Based on this figure, there is dead zone (240 to 0) in which if A
>>  operates after reboot then the seqcnt will always be considered
>>  smaller.  Thus node A needs to maintain the seqcnt in persistent
>>  storage and reuse this on reboot.
> 
> My instinct is there are one of two bugs (maybe both documentation and code):
>   a) node A SHOULD rapidly move from 240 to 0, that the numbers from 240 to
>      0 should be considered "setup", and node A was wrong to advance only
>      to 250, and not as soon as it felt "stable", move to 0.
> 
>   b) that node B, should recognize that during the 240 to 0 stage, that
>      the counters should not be compared.  Anything < 0 is "setup", and is
>      always "new", but that 251 > 250 require immediate action.
> 
> I found it unusual that the lollipop should require 16 values in the stem, I
> think that one ('0') would have worked, but maybe there was some reason to
> prefer 16.
> 
> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
>    
> 
>    
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll