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

[peter van der Stok <[e-mail]>]

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:
> 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 <[e-mail]>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll