Subject: Re: [Roll] Telechat update notice: <draft-ietf-roll-trickle-mcast-11.txt>

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Jan 2015 10:53:59 -0500

After some significant delays, and some minor rework the document is now
going to IESG telechat.
Ines and I thank the authors and the community for their patience.

IETF Secretariat <[email-masked]> wrote:
    > Placed on agenda for telechat - 2015-02-05
    > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Badis Djamaa <[email-masked]>
Date: Mon, 19 Jan 2015 16:25:32 +0000

Hi Michael,

I had some comments about this draft that I sent to the authors. Having not
heard from the authors, I though it might be useful to copy them below

-------------------------------------
Dear authors,

having read and examined the MPL-drafts-07-11 and having worked thoroughly
with Trickle for my PhD, I have some comments regarding MPL's Trickle
parameters.

Draft 11, Section 5.4.  MPL Parameters states:

MPL-TEXT: DATA MESSAGE_IMAX  The maximum Trickle timer interval, as defined in
      [RFC6206 <http://tools.ietf.org/html/rfc6206>], for MPL Data
Message transmissions.  DATA_MESSAGE_IMAX
      has a default value equal to DATA_MESSAGE_IMIN.

Starting from the above statement (dubbed MPL-TEXT), I have two main
comments

1) terminology related: [RFC6206
<https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206>]  (4.1
<https://mail.google.com/mail/u/0/html/compose/static_files/blank_quirks.html#section-4.1>.
Parameters and Variables) defines "The maximum Trickle timer interval" as:

RFC6206-TEXT1:  The maximum interval size, Imax, is described as a number of
      doublings of the minimum interval size (the base-2 log(max/min)).
      For example, a protocol might define Imax as 16.  If the minimum
      interval is 100 ms, then the amount of time specified by Imax is
      100 ms * 65,536, i.e., 6,553.6 seconds or approximately
      109 minutes.

MPL-TEXT refers to RFC6206
<https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206> for
the definition of "The maximum Trickle timer interval". However, I think
"The maximum Trickle timer interval" usage in MPL-TEXT is different than
its definition in RFC6206-TEXT1. Thus, I think it would be better to
explicitly specify what is meant by "The maximum Trickle timer interval" to
avoid any ambiguity.

Note that the same comment is also valid for this MPL text (Draft 11,
Section 5.4.  MPL Parameters )

CONTROL_MESSAGE_IMAX  The maximum Trickle timer interval, as defined
in [RFC6206 <http://tools.ietf.org/html/rfc6206>],
for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a
default value of 5 minutes.

2) Now arriving to the main concern, suppose that  DATA_MESSAGE_IMAX
literally means the maximum trickle interval (the time specified by Imax
using RFC6206
<https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206>
terminology),
then: "DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN."
in MPL-TEXT could result in a "non-wanted" behavior . This is because
RFC6206 <https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206>'s
section 4.2
<https://mail.google.com/mail/u/0/html/compose/static_files/blank_quirks.html#section-4.2>.
Algorithm Description, rule 6 states:

RFC6206-TEXT2: 6.  ...If I is equal to Imin when Trickle hears an
       "inconsistent" transmission, Trickle does nothing...

Recommending "DATA_MESSAGE_IMAX has a default value equal to
DATA_MESSAGE_IMIN." makes the trickle timer always fall under RFC6206-TEXT2
and hence the timer will never get reset when hearing "inconsistencies"

However, if this default recommendation is deliberately designed
considering the above point, then choosing a non-default value of
DATA_MESSAGE_IMAX will result in a different behavior (nodes will reset
their timers when receiving inconsistencies). This might even propagate
faster than the default recommendation.

To avoid the aforementioned ambiguities, I can think of recommending either
a default DATA_MESSAGE_IMAX equals 2*DATA_MESSAGE_IMIN or propose a change
to RFC6206-TEXT2 in the MPL draf, if the current default recommendation is
not deliberately designed to work as shown above. Otherwise, explicitly
state in the MPL text that choosing a non-default value of
DATA_MESSAGE_IMAX may result in different behavior.

3) By the way, RFC6206 also contains a typo, which might confuse the
reader, in the following text (RFC6206 4.2
<https://tools.ietf.org/html/rfc6206#section-4.2>. Algorithm Description,
rule 1):

Current:

1.  When the algorithm starts execution, it sets I to a value in the
       range of [Imin, Imax] -- that is, greater than or equal to Imin
       and less than or equal to Imax.  The algorithm then begins the
       first interval.

Following the definition of the maximum interval size (RFC6206-TEXT1,
above) this rule should be rewritten

Proposed:

1.  When the algorithm starts execution, it sets I to a value in the
       range of [Imin, *Imin x **POW(2, Imax)*] -- that is, greater
than or equal to Imin
       and less than or equal to *the time specified by* Imax.  The
algorithm then begins
       the first interval.

Note that the rest of the rules are written taking into account
RFC6206-TEXT1.

all the best
badis

On 19 January 2015 at 15:53, Michael Richardson <[email-masked]>
wrote:

>     > ID Tracker URL:
> http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
>
>
> --
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Jan 2015 18:20:16 -0000

Hi Badis,
 
You sent your comments to the authors in private? Hmmm, that's a shame.
But thanks for forwarding them to us all now.
 
Since it is now very late in the process for new comments, what I'll do is discuss your mail with the authors and chairs, and pick up any important issues as part of my IESG ballot.
 
Thanks,
Adrian
 
From: Roll [mailto:[email-masked]] On Behalf Of Badis Djamaa
Sent: 19 January 2015 16:26
To: Routing Over Low power and Lossy networks; Michael Richardson
Subject: Re: [Roll] Telechat update notice: <draft-ietf-roll-trickle-mcast-11.txt>
 
Hi Michael,
I had some comments about this draft that I sent to the authors. Having not heard from the authors, I though it might be useful to copy them below
-------------------------------------
Dear authors,
 
having read and examined the MPL-drafts-07-11 and having worked thoroughly with Trickle for my PhD, I have some comments regarding MPL's Trickle parameters. 

MPL-TEXT: DATA MESSAGE_IMAX  The maximum Trickle timer interval, as defined in
      [RFC6206 <http://tools.ietf.org/html/rfc6206> ], for MPL Data Message transmissions.  DATA_MESSAGE_IMAX
      has a default value equal to DATA_MESSAGE_IMIN.
Starting from the above statement (dubbed MPL-TEXT), I have two main comments
1) terminology related: [RFC6206 <https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206> ]  ( <https://mail.google.com/mail/u/0/html/compose/static_files/blank_quirks.html#section-4.1> 4.1.  Parameters and Variables) defines "The maximum Trickle timer interval" as:
RFC6206-TEXT1:  The maximum interval size, Imax, is described as a number of
      doublings of the minimum interval size (the base-2 log(max/min)).
      For example, a protocol might define Imax as 16.  If the minimum
      interval is 100 ms, then the amount of time specified by Imax is
      100 ms * 65,536, i.e., 6,553.6 seconds or approximately
      109 minutes.
MPL-TEXT refers to RFC6206 <https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206>  for the definition of "The maximum Trickle timer interval". However, I think "The maximum Trickle timer interval" usage in MPL-TEXT is different than its definition in RFC6206-TEXT1. Thus, I think it would be better to explicitly specify what is meant by "The maximum Trickle timer interval" to avoid any ambiguity. 

Note that the same comment is also valid for this MPL text (Draft 11, Section 5.4.  MPL Parameters )
CONTROL_MESSAGE_IMAX  The maximum Trickle timer interval, as defined in [RFC6206 <http://tools.ietf.org/html/rfc6206> ], 
for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a default value of 5 minutes.
 
2) Now arriving to the main concern, suppose that  DATA_MESSAGE_IMAX literally means the maximum trickle interval (the time specified by Imax using RFC6206 <https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206>  terminology), then: "DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN." in MPL-TEXT could result in a "non-wanted" behavior . This is because RFC6206 <https://mail.google.com/mail/u/0/html/compose/static_files/rfc6206> 's section  <https://mail.google.com/mail/u/0/html/compose/static_files/blank_quirks.html#section-4.2> 4.2.  Algorithm Description, rule 6 states:
RFC6206-TEXT2: 6.  ...If I is equal to Imin when Trickle hears an
       "inconsistent" transmission, Trickle does nothing...
Recommending "DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN." makes the trickle timer always fall under RFC6206-TEXT2 and hence the timer will never get reset when hearing "inconsistencies" 
However, if this default recommendation is deliberately designed  considering the above point, then choosing a non-default value of DATA_MESSAGE_IMAX will result in a different behavior (nodes will reset their timers when receiving inconsistencies). This might even propagate faster than the default recommendation.
 
To avoid the aforementioned ambiguities, I can think of recommending either a default DATA_MESSAGE_IMAX equals 2*DATA_MESSAGE_IMIN or propose a change to RFC6206-TEXT2 in the MPL draf, if the current default recommendation is not deliberately designed to work as shown above. Otherwise, explicitly state in the MPL text that choosing a non-default value of DATA_MESSAGE_IMAX may result in different behavior.
 
3) By the way, RFC6206 also contains a typo, which might confuse the reader, in the following text ( <https://tools.ietf.org/html/rfc6206#section-4.2> RFC6206 4.2. Algorithm Description, rule 1): 
Current:
1.  When the algorithm starts execution, it sets I to a value in the
       range of [Imin, Imax] -- that is, greater than or equal to Imin
       and less than or equal to Imax.  The algorithm then begins the
       first interval.
Following the definition of the maximum interval size (RFC6206-TEXT1, above) this rule should be rewritten 
Proposed:
1.  When the algorithm starts execution, it sets I to a value in the 
       range of [Imin, Imin x POW(2, Imax)] -- that is, greater than or equal to Imin 
       and less than or equal to the time specified by Imax.  The algorithm then begins 
       the first interval.
Note that the rest of the rules are written taking into account RFC6206-TEXT1.
 
all the best
badis
 
On 19 January 2015 at 15:53, Michael Richardson <[email-masked]> wrote:

--
Michael Richardson <[email-masked] <mailto:[email-masked]> >, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/