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

[Rahul Jadhav <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]> 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) <
> [e-mail]> 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 <[e-mail]> *On Behalf Of *Rahul Jadhav
>> *Sent:* mardi 26 novembre 2019 15:25
>> *To:* Routing Over Low power and Lossy networks <[e-mail]>
>> *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) <
>> [e-mail]> 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 <[e-mail]> *On Behalf Of *Rahul Jadhav
>> *Sent:* mardi 26 novembre 2019 13:47
>> *To:* Routing Over Low power and Lossy networks <[e-mail]>
>> *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: <[e-mail]>
>> Date: Tue, 26 Nov 2019 at 20:42
>> Subject: [Roll] I-D Action: draft-ietf-roll-rpl-observations-03.txt
>> To: <[e-mail]>
>> Cc: <[e-mail]>
>>
>>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>