Re: [Roll] Fwd: I-D Action: draft-ietf-roll-rpl-observations-03.txt

Rahul Jadhav <rahul.ietf@gmail.com> Fri, 29 November 2019 04:02 UTC

Return-Path: <rahul.ietf@gmail.com>
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 F288D1200F4 for <roll@ietfa.amsl.com>; Thu, 28 Nov 2019 20:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XtimmCd1J3YX for <roll@ietfa.amsl.com>; Thu, 28 Nov 2019 20:02:20 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD77120860 for <roll@ietf.org>; Thu, 28 Nov 2019 20:02:20 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id j6so21414571lja.2 for <roll@ietf.org>; Thu, 28 Nov 2019 20:02:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LYSOwiBXrRmThABbdK51kwCk1LwYLfzKwyNjI2nfS0o=; b=mjDzcooigukbHussJzdzaljW9poHb4AyWWOn8NfzAMzmqCBhr++ysp9Mfubhv7km5T j4gnpYeWLK1sX0YYqQ7wVbGHXNDbv2HwHkIYSaKDFl1eWnUbFCOZ//osy8c1Y8Lnh3jR EEItjlz2ZNSsvYLP2t6QpC734oIicOi07xb3Cb7I6sia9+YOG/64VR6R0YMazC2GrMcR k7MXDANbtl5sNtMri6TtqbAmJzILuGUBIg8iridl5+lyAbGDwwYRbPMRbYX/Yg2+NQfa TtSpvd9X3jVsu9/BDREsXUMe6VjclgT95jVGhTOwlR5TMxXYDy+I9OnLqAu+Byq7I/k6 lSYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LYSOwiBXrRmThABbdK51kwCk1LwYLfzKwyNjI2nfS0o=; b=N9J0OeptmSl8MVI9h4Y8yLWLYlrItsEXPVIV4BvQubtW8T1c741m1vZzubwYo6FMim 2lhJr2Tllr4oA4LIIjzt70GSa0Ms4rPO1EvBEzoCr8gnt86LM8v7xcYmWTwR5rG2xz2q EYbAbopFoslxo7MR2WgFNVjtLO4AzOD9ejp8KuxjkTBF4P58OAE2yHAyn/CkSw4RAVh2 f5dPJdJgoIUkD6UQIOo/ms0/aXteST/n1q+OYkeqVczh2u4VRDKojODhZzd5ONlxv6+s 6gn5Ta2J9xkaOp5qmy6Ky7LfmzbOAOSn6zKaZxDNeAuzDQXh0zIIR9AG8kKMCNjrG7qY AjWA==
X-Gm-Message-State: APjAAAVh3CZ5Bo2AP8Sxz8kQI3hV7kD1bycqIaK67i/z+psp4W47yc35 IQ/8O0/Q3QJFSKMBrtjSXfhKJsjB0ViVKXgXrna9Iq46
X-Google-Smtp-Source: APXvYqz17FLls5EAHE9Km9thPgUgbWMvSTKCFX52xs4nqHI/Y41EjdROtkLPwFNpWi0WmUcsGJxKNjJO10/MoLnfUKo=
X-Received: by 2002:a2e:b0e1:: with SMTP id h1mr3401127ljl.22.1575000138023; Thu, 28 Nov 2019 20:02:18 -0800 (PST)
MIME-Version: 1.0
References: <157477212600.13715.10647534303499379032@ietfa.amsl.com> <CAO0Djp1K=_6DwAQ31+Y8raVkfBP7=YobaQkOzrtBCB9Da3Fd0A@mail.gmail.com> <MN2PR11MB35651EEACA6CB142CB57D1F4D8450@MN2PR11MB3565.namprd11.prod.outlook.com> <CAO0Djp2kX52TfrwJSzuBB2bOLoE46WvJOw-XJ-9D66U-nqXeuQ@mail.gmail.com> <MN2PR11MB3565F261BED62B3A70FEE564D8450@MN2PR11MB3565.namprd11.prod.outlook.com> <CAO0Djp3+XTtr8HAJPaZJMZ=Pj2gKjbJk4MG=AkjcBG-fJQud0A@mail.gmail.com> <D577BCA4-9DCC-4278-8CA3-56AC17E96D9A@cisco.com>
In-Reply-To: <D577BCA4-9DCC-4278-8CA3-56AC17E96D9A@cisco.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Fri, 29 Nov 2019 12:02:06 +0800
Message-ID: <CAO0Djp35E-db8qBC92qwErqo88DPhqKpBBfj1Gh-KCM8HycfpQ@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bf86060598744bc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/2nzawdnyRPFeby-5uxfOdxnv0u0>
Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-rpl-observations-03.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 29 Nov 2019 04:02:24 -0000

Thanks Pascal for the review of the update and comments.
Please find my comments inline.

On Thu, 28 Nov 2019 at 23:25, Pascal Thubert (pthubert) <pthubert@cisco.com>;
wrote:

> Hello Rahul
>
> The text works. I’d have liked that it makes a distinction between
> resetting and restarting. The former acts on parameters the latter on a
> running timers.
>
> Resetting means I<-Imin. That’s it.
>
[RJ] Imo, This is clarified in the text. Reset simply means go back to
Imin, unless you are already in Imin, in which case, do nothing.


> Restarting the timer means an API call to the kernel timer services.
> These are different things and it would be more clear if we separated
> them.
>

> If I is not Imin then resetting means changing the value of I; this
> implies that the current running timer operates on wrong parameters and
> this may time out too late. The simple thing to do to solve this is to
> restart the timer based on the new parameters.
>

[RJ] This again is made clear by the statement which says that the timer
should go back to Imin if I is not Imin and the nodes hears an inconsistent
transmission. I don't think "wrong parameters" would be the term to use
because the parameters were not wrong when the interval started. The
parameters were invalidated at a later point in time.


> But if I is already set into Imin resetting it (to Imin) produces no
> effect. Which means that the running timer operates on the right parameters
> and doesn’t need to be restarted.
>
[RJ] If I is at Imin, then the implementation MUST NOT do anything. This is
clear as part of 6206 as well as in the example/text in the updates.

It is possible that I am not able to catch your drift here. Would it be
possible for you to propose 'specific text' in the context?


>
> Regards,
>
> Pascal
>
> Le 28 nov. 2019 à 09:06, Rahul Jadhav <rahul.ietf@gmail.com>; a écrit :
>
> 
> Hi Pascal,
>
> I have updated as follows. This clarifies the interpretation and then also
> explains specifically in context to multicast DIS/DIO operation.
>
> "
>
> 5.  Interpreting Trickle Timer
>
>    Trickle timer defines a mechanism to reset the timer.  Trickle timer
>    reset is unlike regular periodic timers wherein the timer is simply
>    reset to start again.  Reset of trickle timer implies resetting the
>    trickle back to Imin and starting with a new interval as mentioned in
>    Section 4.2 of [RFC6206].
>
> |----|--------|----------------|--------------------------------| . . . . . .
>  Imin   I2             I3                       I4                       I5
>
>                      Figure 4: Trickle Timer Operation
>
>    The above figure shows an example of trickle intervals.  An interval
>    is double that of the previous interval size.  Section 4.2. of
>    [RFC6206] states that,
>
>    "If Trickle hears a transmission that is "inconsistent" and I is
>    greater than Imin, it resets the Trickle timer.  To reset the timer,
>    Trickle sets I to Imin and starts a new interval as in step 2.  If I
>    is equal to Imin when Trickle hears an "inconsistent" transmission,
>    Trickle does nothing.  Trickle can also reset its timer in response
>    to external "events"."
>
>    Thus if the trickle timer has advanced to subsequent intervals i.e.,
>    >= I2, then a reset of trickle timer implies going back to Imin.
>    However, if the trickle timer is currently in Imin and if it hears an
>    inconsistent transmission then it does nothing.
>
>    In context to multicast DIS/DIO operation, this implies that if the
>    DIO trickle timer is already at Imin and if the node hears a
>    multicast DIS, then the timer does nothing.  It MUST NOT reset the
>    timer again in this case.
>
>    An implementation MUST never restart the timer within an interval.
>    For e.g., in the above figure, if the timer is in interval I2, the
>    implementation MUST never restart the timer to the beginning of the
>    current interval i.e., I2.  If the timer is in interval T2 and if the
>    reset is to be done then the interval is set back to Imin.  If the
>    timer is already in Imin, then the reset should do nothing.
>
> "
> https://github.com/roll-wg/rpl-observations/pull/8
>
> Best,
> Rahul
>
> On Tue, 26 Nov 2019 at 22:31, Pascal Thubert (pthubert) <
> pthubert@cisco.com>; wrote:
>
>> Hello Rahul :
>>
>>
>>
>> I mean that if the spec says reset trickle and I is already Imin then the
>> timer already operates within the bounds that are expected so it does not
>> need to be restarted. Now if I was larger than Imin at the time of the
>> reset then it was operating out of bounds and needs to be restarted to
>> timeout earlier. Same if K changes, e.g., by configuration. The current
>> timer operates with the wrong parameters and should be restarted.
>>
>>
>>
>> Makes more sense?
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* Roll <roll-bounces@ietf.org>; *On Behalf Of *Rahul Jadhav
>> *Sent:* mardi 26 novembre 2019 15:25
>> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>;
>> *Subject:* Re: [Roll] Fwd: I-D Action:
>> draft-ietf-roll-rpl-observations-03.txt
>>
>>
>>
>> Hi Pascal,
>>
>>
>>
>> On Tue, 26 Nov 2019 at 20:56, Pascal Thubert (pthubert) <
>> pthubert@cisco.com>; wrote:
>>
>> Hello Rahul
>>
>>
>>
>> I believe I undertand what you want to d but the text below is really
>> unclear to me
>>
>> “
>>
>>   Implementations MUST not restart the trickle timer to the
>>
>>   instantaneous value of I which could have been advanced over a
>> period
>>
>>   of time.
>>
>> “
>>
>> [RJ] ok. But I could not think of anything better. May be I should use
>> asciiart and explain with an example. What do you think?
>>
>>
>>
>> What I thought you’d write is that the trickle time needs only be
>> restarted is one value I, K has changed, making the current run
>> incompatible with the setting.
>>
>> [RJ] This is unclear for me. Specifically "trickle time needs only be
>> restarted is one value I, K has changed"
>>
>>
>>
>>
>>
>> All the best
>>
>>
>>
>> Pascal
>>
>>
>>
>>
>>
>> *From:* Roll <roll-bounces@ietf.org>; *On Behalf Of *Rahul Jadhav
>> *Sent:* mardi 26 novembre 2019 13:47
>> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>;
>> *Subject:* [Roll] Fwd: I-D Action:
>> draft-ietf-roll-rpl-observations-03...txt
>>
>>
>>
>> Hello All,
>>
>>
>>
>> The update contains clarification regarding Trickle timer reset handling.
>>
>>
>>
>> Regards,
>>
>> Rahul
>>
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>;
>> Date: Tue, 26 Nov 2019 at 20:42
>> Subject: [Roll] I-D Action: draft-ietf-roll-rpl-observations-03.txt
>> To: <i-d-announce@ietf.org>;
>> Cc: <roll@ietf.org>;
>>
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Routing Over Low power and Lossy
>> networks WG of the IETF.
>>
>>         Title           : RPL Observations
>>         Authors         : Rahul Arvind Jadhav
>>                           Rabi Narayan Sahoo
>>                           Yuefeng Wu
>>         Filename        : draft-ietf-roll-rpl-observations-03.txt
>>         Pages           : 18
>>         Date            : 2019-11-26
>>
>> Abstract:
>>    This document describes RPL protocol design issues, various
>>    observations and possible consequences of the design and
>>    implementation choices.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-03
>> https://datatracker.ietf.org/doc/html/draft-ietf-roll-rpl-observations-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-rpl-observations-03
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp...ietf.org/internet-drafts/
>> <ftp://ftp.ietf.org/internet-drafts/>
>>
>> _______________________________________________
>> 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
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>