Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

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

Hi all,

I should like to comment on the point below.

> 
> 2) "Do you agree that all nodes in a given LLN SHOULD agree on a
> commonvalue for Imin? …… "
> 
> I believe it is requirement that all devices in a given MPL Domain
> MUST agree on a common value for IMIN, IMAX and k. In terms of a
> default, we can certainly create such values applicable to given
> deployment topology and an assumed messaging profile but I really
> think some work should go into an applicability statement that would
> provide additional guidance on how to tune these values. I think I
> mentioned this before but we did (in ZigBee IP) create a 30 node, 3
> hop network supporting a ROLL RPL instance, instrumented all devices,
> created a single multicast message and measured how many devices in
> the network saw at least a single copy of the transmission using
> various settings for IMIN, IMAX and k. A process similar to this (with
> knowledge of the topology and messaging profile) is needed for tuning
> these values in a real deployment setting.

After looking for an appropriate setting for Imin, Imax and k, I slowly 
learnt that these settings depend on the topology of the network, the 
load of the network, the setting of the MAC, and eventual real-time 
requirements (e.g. there is a deadline), and the value of that deadline.
The setting of k for example is related to the number of MPL repeaters 
that receive a new message and start to resend it, possibly interfering 
with each other and probably incrementing the c value of the next hop, 
where the maximum value of c is related to the Imin value.
Sending a packet takes as little as 3 ms, but when the MAC stores three 
packets and the they all back-off a maximum number of times, delays of a 
few hundred milliseconds to seconds become possible.
When there is buffer space for packets before and in the MAC, the Imin 
value can be chosen as low as 1 ms, the resend of packets is then 
completely determined by the load on the network.

And there are many more conditions and mutual dependencies.

So, I suggest to leave the default values mentioned in the draft as they 
are, and leave the tuning of the parameters to the people who deploy and 
have experience with a certain class of networks. The applicability 
statement can give configuration examples and suggest some best practice 
values.
I think an analysis of a set of configurations with temporal objectives 
and network load is too much text for the applicability statement, and 
is best referred to from the applicability statement.

Peter