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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 13 May 2018 16:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BCC126BF3 for <roll@ietfa.amsl.com>; Sun, 13 May 2018 09:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2Da5MTPSily for <roll@ietfa.amsl.com>; Sun, 13 May 2018 09:55:22 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C5A1242EA for <roll@ietf.org>; Sun, 13 May 2018 09:55:22 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B989F20090 for <roll@ietf.org>; Sun, 13 May 2018 13:07:25 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 4D5922674; Sun, 13 May 2018 12:55:02 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4AA00264F for <roll@ietf.org>; Sun, 13 May 2018 12:55:02 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <5BEB0BFF-8BA1-4D6D-83DA-AC75F8AD4AEC@cisco.com>
References: <8EC2893F-731B-439D-86FE-984505349D8D@tzi.org> <982B626E107E334DBE601D979F31785C5DBCD1B4@BLREML503-MBS.china.huawei.com> <22477.1525301358@localhost> <CAO0Djp1sCSFJSZSbVNL+RLgV2FrjwZQrJ6p-9ExndMbQqua-QA@mail.gmail.com> <0522ea86b4234490bdd56b1428db0762@XCH-RCD-001.cisco.com> <29982.1525354228@localhost> <685a615a79e8442f9f7b19983ef2a36d@XCH-RCD-001.cisco.com> <25461.1525367718@localhost> <982B626E107E334DBE601D979F31785C5DBE374F@BLREML503-MBX.china.huawei.com> <23345.1525709153@localhost> <CAO0Djp3a2AXMC3ORDhTGbyhwr09nw+8poDeQL03V7t2Bksp-bQ@mail.gmail.com> <b3265ca6f74545468c00007dadaa0fb7@XCH-RCD-001.cisco.com>, <17986.1526151471@localhost> <5BEB0BFF-8BA1-4D6D-83DA-AC75F8AD4AEC@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 13 May 2018 12:55:02 -0400
Message-ID: <22387.1526230502@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/I3crbVe_nqv5KVDzNDgAkDz7KiU>
Subject: Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 May 2018 16:55:25 -0000

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?

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

-- 
]               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    [