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

["Adrian Farrel" <[e-mail]>]

Hi Badis,

I'm finally processing your comments on this draft before it goes in front of the IESG on Thursday.

Comments in line.

> Draft 11, Section 5.4.  MPL Parameters states:
>
> MPL-TEXT: DATA MESSAGE_IMAX  The maximum Trickle timer interval, as defined in
>      [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]  (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 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. 

I agree this is somewhat confusing. 
However, it states that Imax "is described as a number of doublings" not that Imax is a count of doublings.
Sigh - we should have made this clearer in 6206.
Of course, an implementation can do this however it likes, but Imax specifies an amount of time, and I think 6206 is clear about this in the text you quoted.

That means that the text in this draft is also unambiguous that Imax specifies a time.

> 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], for MPL Control Message transmissions.
> CONTROL_MESSAGE_IMAX has a default value of 5 minutes.

Same answer :-)

> 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 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's 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.
 
Well, we can come back and work on 6206, but we only have *this* document in front of us at the moment.

I tripped over the IMAX==IMIN piece until reading (later in the section) the explanation...

|  Setting DATA_MESSAGE_IMAX to the same as DATA_MESSAGE_IMIN
|  in this case is acceptable since subsequent MPL Data Message
|  retransmissions are triggered by MPL Control Messages, where
|  CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN.

> 3) By the way, RFC6206 also contains a typo, which might confuse the reader,
> in the following text (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.

This could be approached with an Errata Report for RFC 6206, but I think you have fixated on how Imax is expressed, rather than the fact that Imax is a time.

Thanks,
Adrian