Re: [Roll] Trickle Reset vs Restart

Abdussalam Baryun <> Mon, 25 November 2019 06:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 126FC120800 for <>; Sun, 24 Nov 2019 22:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I8f3UmmVmIFC for <>; Sun, 24 Nov 2019 22:30:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20E3B120098 for <>; Sun, 24 Nov 2019 22:30:22 -0800 (PST)
Received: by with SMTP id d5so11627058otp.4 for <>; Sun, 24 Nov 2019 22:30:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NBdYL8Mbu3Lef3pv9uYheGei+gm0JzAhmWldaJ1LcHE=; b=pYKKK/poNCokvS56qY5h/QRxJv9s24jUx5KrR8Jz4aa+ARSZdvwezaEwDMvTZIJsz0 Wz8FV1e/mR3YB0LSPkd2xGx8jqoMRxlJhTdXNB9z7LszG8bzqHcWc6wlq6MHjR1BKRNx sQbs++VwhYA6/snaCY5odCmxaIg4Sfhp4jjMJKFz4Z7Qph5GnmeBBUjAB5WvKdHfGPy/ derhP+6mjRpG7xAJKLYTkiGXWs8qxoiWpK9Bgsmj4iBKwyrK4jG+BaFiHa6OnMs8HGgf NjPyGUumvYymE6RT7msFZpHGAMLSpQV7dmuyrtQqsLQoNXM7EgC1M5Mp06HNY0wRBfha kEaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NBdYL8Mbu3Lef3pv9uYheGei+gm0JzAhmWldaJ1LcHE=; b=YLNa435lSE2UNd0Ujp64URV8DRtAruEdtS31QEzd0i4EUxWfWCPIrb5SijeFRefXw7 /qiTUqnqjxr0neR4Y39oTFtdXyp1Wuvco2kTCVG0Ny9tQKPGeA2K3ZYgFjwVqkTm0G6C /Vm7wybbBdqo9jQuRj1YEuaHv+z/C+cWYnvJe94ZmcZ+bJNbKSVJbQLlrco3pjnQVOqV 0q/QdUarL2FYq6DbCOAFB28qRk/EHx6f30/qiU4XE6kvdOpaXCjDkHA3HcG/9Law104g 7AajYsM1eduXXldxgUHJJVryjeQmJY84Dgzdi4C2deLFrWDBXsst2m4BbHKLPFn8oZyw d4XA==
X-Gm-Message-State: APjAAAWduuzlRASDH358jRm5BWqVeVaWYe7QY6eETDvrdREKLkjCykrH HgNlv8CTKmAtF1mIsiYn5wV3yjNS/YllGfauo59LaA==
X-Google-Smtp-Source: APXvYqxdr6PBVXK63kXQrqO4397KWVggzBt869fbN0fUeyq4Iob9RkJV+2rUIROp5nLq8WwOYeJ0C5Y7QcGw2pn+ifM=
X-Received: by 2002:a9d:7ad7:: with SMTP id m23mr19490620otn.190.1574663421275; Sun, 24 Nov 2019 22:30:21 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Abdussalam Baryun <>
Date: Mon, 25 Nov 2019 08:29:49 +0200
Message-ID: <>
To: Routing Over Low power and Lossy networks <>
Content-Type: multipart/alternative; boundary="000000000000ddb17e059825e5d0"
Archived-At: <>
Subject: Re: [Roll] Trickle Reset vs Restart
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Nov 2019 06:30:24 -0000

That depends on the Protocol/Standard using Trickel Algorithm.

Restart can be used. So if such protocol using this algorithm needs
Restart, then it can be used for protocol performance and usecases.
Reset is always needed by Trickel ( it is in its six Rules, section 4) that
is in the RFC6206 specification, and also Reset can be needed/used by the
protocol using the Trickel (mentined in section 5).

Overall, any protocol/standard using this RFC6206 algorithm must specify
what does it reacts when inconsistency is detected. That reaction can be
Restart algorithm.

On Thu, Nov 21, 2019 at 7:02 AM Rahul Jadhav <> wrote:

> During the IETF106 roll-session, we discussed resetting vs restarting
> Trickle. Pascal raised this in another mail as well.
> After checking RFC 6206 (Section 4.2), I found that there is only one
> notion i.e., to reset Trickle timer, which means going back to Imin and
> starting a new interval.

not one notion I think,

> There is no notion of restarting the current timer for the instantaneous
> value of I.
> This is what my understanding was and reset is all that is needed, IMO. I
> would like to be corrected if there is any use-case, where restarting the
> timer would be needed.

I think Restart is needed by RPL at some topology changes with
inconsistency, or needed at protocol configuration changes at runtime. We
don't forget that C6206 is so far from perfect (these words mentioned in
section 6.7), with some efficient results. However, it may need simple
restart or reconfiguring its parameters at cases that can be noticed by
RFC6206 operational considerations section.

> We may not need any clarifications on this particular issue. Or do you
> think we should still keep this as a note for implementors in the
> observations draft?

IMO, clarification in drafts is always good specially in a
standard/updating_standard draft.