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

Hello Rahul:

I think it is clear that there are corner cases when not using a persistent storage, and that the problem is not a dead lock but something that solves itself sooner or later. This leaves room for different device cost for different usages.

I agree we can reread the whole DTSN text and improve it. I'll need to do that before agreeing on any proposed update.

To answer your questions: Looking at it again, I'm not sure we need to declare it a lollipop counter. It was not listed as such but I fail to remember why. Maybe it was effectively because it only needs to change to trigger the pull. If it is picked at random and uses the same value as before, the first retry will be a change and from there you go.

All the best,

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Arvind Jadhav
> Sent: lundi 14 mai 2018 17:43
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear
> leveling
> 
> Please find my comment inline...
> 
> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: 14 May 2018 13:14
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear
> leveling
> 
> Hello Michael:
> 
> > -----Original Message-----
> > From: Roll <roll-bounces@ietf.org> On Behalf Of Michael Richardson
> > Sent: dimanche 13 mai 2018 18:55
> > To: Routing Over Low power and Lossy networks <roll@ietf.org>
> > Subject: Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1:
> > Wear leveling
> >
> >
> > Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> >     > 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.
> >
> > okay, so with TSCH it would make sense to start a higher number?
> 
> [PT>] Yes, I think so. It also depends on the chances to reboot again soon.
> 
> >     > 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.
> >
> > Yes, agreed.
> > The goal is to have a way for children to see that the node is freshly
> > rebooted and to reset their threshold.
> >
> >     > 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...
> >
> > Maybe there is no change, but you claim the DTSN does need to be written
> to
> > flash, and Rahul says that it must be.   (Correct me if my understanding is
> > wrong).
> > A protocol which does not require flash writes is clearly better.
> >
> [PT>] There is DTSN and there are all the other numbers. The hints I'm giving
> above are for general sequence counters in RPL.
> DTSN is in fact simpler since it is not propagated by the protocol over multiple
> hops. A node that talks one-to-one with another will hopefully not receive
> packets out of order - unless packets can mix up in the transmitter queues? So
> literally any change in the DTSN could be seen as a new DTSN, regardless of
> whether the new value is higher or lower. We may improve the text in RPL to
> indicate that; Not sure we really need to list it in section 7 after all. Maybe we
> need more thoughts/reread of the spec, but it feels like DTSN can be started
> at boot at any random value and any change in DTSN is a pull.
> 
> [RJ] Any change in DTSN is a pull contradicts lollipop behavior. So isn’t dtsn a
> lollipop counter unlike our previous discussion? Also in another scenario, if
> the chosen random value turns out to be the same at which the node
> previously rebooted, then still it is an issue.
> 
> Cheers,
> 
> Pascal
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll