Subject: [Roll] ticket - 172 - clarify units of trickle timers

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Aug 2015 08:27:57 -0400

https://tools.ietf.org/wg/roll/trac/ticket/172

This ticket was opened in response to a DISCUSS from AD Alia Atlas,
on the draft-ietf-roll-mpl-parameter-configuration document.

As a result of this DISCUSS the processing of trickle-mcast was held
up at the RFC-editor, as there was concern that we needed to fix that
document.  Ines and I are looking for opinions from the WG about this
situation; better text, even just "yes, you described the problem correctly"

The specific confusion is that draft-ietf-roll-mpl-parameter-configuration
and trickle-mcast are not explicit enough about the units of IMIN and IMAX
values.

Jonathan Hui commented that the origin of the problem is
really RFC RFC 6206, and he wrote on a thread involving the ADs:

       - On one hand, RFC 6206 says "the maximum interval size Imax", which
       is an absolute value.
       - On the other hand, RFC 6206 says that Imax "is described as a number
       of doublings of the minimum interval size", which is a relative value.

       - Later, RFC 6206 uses Imax as if it were an absolute value. For
       example, "When the algorithm starts execution, it sets I to a value in
       the range of [Imin, Imax]". In another example, "Nodes with small Imax
       values will transmit faster, suppressing those with larger Imax
       values. The nodes with larger Imax values, always suppressed, will
       never transmit." That statement only makes sense if Imax was an
       absolute value, and not relative to Imin.

       - RFC 6206 also uses Imax as it it were a relative value. "Note that
       mismatched Imin values and matching Imax doubling constants will lead
       to mismatched maximum interval lengths."

It seems clear to me that it doesn't really *internally* matter if Imax is a
timer or a doubling of Imin, as long as it can be used an alarm that causes
the trickle algorithm to run.  It is only when we get to
draft-ietf-roll-mpl-parameter-configuration when we put these values
on the wire that we have to deal with it clearly.

mpl-paramaeter-configuration says (section 2.1):

   Note that all time values (Trickle timers and expiration periods) are
   in TUNIT milliseconds precision.  For example, if TUNIT is 20 and the
   data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
   DM_IMIN shall be set to 50.

and I suggest that it instead say:

   Note that time values DM_IMIN, DM_T_EXP, C_MIN, C_T_EXP are in units
   of TUNIT. TUNIT is a multiplier, and is in units of miliseconds.
   For example, if TUNIT is 20 and the
   desired data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms,
   then DM_IMIN shall be set to 50 (1000ms/ 20 = 50).

   Time values: DM_IMAX, and C_IMAX are in multiples of the respective
   DM_IMIN and C_IMIN values, so if a DM_MIN value of 50 (1000ms) is
   encoded, and DM_IMAX contains the number 4, then the DATA_MESSAGE_IMAX value
   would have be 4000ms (4s).

Also, mpl-parameter-configuration needs a reference to 6206.

As such I don't think we need to fix anything in the trickle-mcast document
itself.

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

---

From: peter van der Stok <[email-masked]>
Date: Mon, 17 Aug 2015 09:15:25 +0200

Hi Michael,

thanks for trying to solve this issue.
I must confess that I had not recognized the problem.
For interoperability is seems an issue when values are initialized (as 
you point out as well)
It will be a nuisance if sets of nodes must be initialized with 
different Imin and Imax values to reach the same behaviour.
The same problem will occur when a YANG (SMIv2) description is made for 
managing these parameters.

Suggestion: write an ERRATA document for RFC6206 which then solves 
draft-ietf-roll-trickle-mcast-12 issue.

Peter

Michael Richardson schreef op 2015-08-14 14:27:
> The specific confusion is that 
> draft-ietf-roll-mpl-parameter-configuration
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2015 11:04:27 -0400

peter van der Stok <[email-masked]> wrote:
    > It will be a nuisance if sets of nodes must be initialized with different
    > Imin and Imax values to reach the same behaviour.

I think that we expect that Imax is in units of multiple of Imin, which
is in units of TUNIT.  Is that part at least, non-controversial?

    > draft-ietf-roll-trickle-mcast-12 issue.

I think that 6206 doesn't care what units are expressed internally.
Do any math in 6206 depend upon an integer multiple relationship between Imin
and Imax?

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 17 Aug 2015 11:27:22 -0400

On Mon, Aug 17, 2015 at 11:04 AM, Michael Richardson <[email-masked]>
wrote:

> different
> Imax is expressed as *doublings* of Imin, which is a tighter constraint
than "multiple".
It also represents an upper bound on the interval length.

See rule 5 of RFC 6206:

5.  When the interval I expires, Trickle doubles the interval length.
    If this new interval length would be longer than the time
    specified by Imax, Trickle sets the interval length I to be the
    time specified by Imax.

Regards, Kerry

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2015 13:31:52 -0400

> Imax is expressed as *doublings* of Imin, which is a tighter
    > constraint than "multiple".

so, if the Imax field contains "5", does that mean that
   Imax = 2^5 * Imin (* TUNIT)

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 17 Aug 2015 14:12:23 -0400

On Mon, Aug 17, 2015 at 1:31 PM, Michael Richardson <[email-masked]>
wrote:

> According to the example in Section 4.1 of RFC 6206, yes.  It refers
to "the amount of time specified by Imax" (which should probably have
its own name to avoid confusion).

Kerry

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Aug 2015 20:04:08 -0400

>> I think that we expect that Imax is in units of multiple of
    >> Imin,
    >> which

    > Imax = 2^5 * Imin (* TUNIT)

    kerry> According to the example in Section 4.1 of RFC 6206, yes. It refers
    kerry> to "the amount of time specified by Imax" (which should probably have
    kerry> its own name to avoid confusion).

I'd like the DHCP parameter document to more closely refer to this, and
perhaps even copy the example from 6206 then.

---

From: Yusuke DOI <[email-masked]>
Date: Mon, 24 Aug 2015 09:48:38 +0900

Thanks for clarifications.
I'll update the document on this week. Sorry for late update.

Yusuke