Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04

[Don Sturek <[e-mail]>]

Hi Peter,

One thing I forgot to mention.  For the 30 nodes/3 hops, we isolated two
parts of the network such that 15 devices on each half had upward paths to
the DAG root.   This allowed us to model the network as if the DAG root
were in the center of two 15 node network segments of hop count 3 from the
root.   This forced the multicast distribution to transmit all of the way
up to the DAG root and back down to service devices on the other half of
the network segment.

Don


On 3/31/13 5:16 AM, "peter van der Stok" <[e-mail]> wrote:

>Hi Don,
>
>Nice to read that some of my conclusions are confirmed by real
>experience.
>The behavior you sketch is also recognized by me.
>
>Currently, I try to analyze timing behavior for 1 to 2 hop networks
>including a 10% loss on a link between seed and a destination.
>I am not interested in responses (for the moment).
>But your aim to have a 100% reception probablity is certainly shared.
>
>Let's compare results when my understanding of this simple network
>topology has increased.
>
>Greetings,
>
>peter
>
>Don Sturek schreef op 2013-03-30 14:11:
>> Hi Peter,
>> 
>> What you wrote below sounds quite correct.   Given our testing, your
>> statement that that recommend default paramters depend on the timing
>> characteristics of the application and topology of the network aligns
>> very
>> well with the test results we gathered.
>> 
>> Our test used our assumed topology (30 node network with 3 hops).   We
>> created the network using IEEE 802.15.4 devices connected via wires on
>> SMA
>> connectors (with attenuators to reflect distance between the devices).
>> Our test set up was to create a multicast message targeting from 1 to
>> 8
>> devices in the network where each of the targeted devices was to
>> create a
>> multicast message in response (we were testing how mDNS would work
>> using
>> Trickle Multicast in our network).   Our success criteria was to see
>> that
>> every node in the network (100% coverage on the requst) saw the
>> original
>> multicast request and that the requestor would see all of the
>> responses
>> (100% coverage on the responses received).   We ran quite a few tests
>> with
>> varying numbers for Imin, Imax, tdell, k, etc.   Intiially, we wanted
>> the
>> window to be small thinking that would best service the
>> requests/responses
>> but could only get to around 60% of requests seen and responses
>> received.
>> Finally, we had to set Imax out to 512ms to achieve our goal.   One
>> clear
>> observation is that these settings were definitely tied to the number
>> of
>> devices in the network and topology.
>> 
>> I know for lighting applications that multicasts must be received
>> within
>> 250ms.   That was not our use case so we did not impose this
>> restriction.
>> It would have been interesting to see if we could have achieved both
>> goals:   all devices seeing the request AND the multicast request
>> delivered within 250ms.
>> 
>> Don
>> 
>> 
>> On 3/30/13 5:24 AM, "peter van der Stok" <[e-mail]> wrote:
>> 
>>> Hi Don, Kerry,
>>> 
>>> 
>>> As I tried to express earlier, I am not too happy with the suggested
>>> default values for the mpl parameters.
>>> Their recommended values very much depend on the timing
>>> characteristics
>>> of the application and the topology of the network.
>>> I think it is more appropriate to have these values cited in the
>>> applicability statements (if they are focused enough).
>>> 
>>> Coming back to simulation c.q. operation results:
>>> I can well imagine that with a network that is loaded for a few
>>> percent
>>> of the time with mpl messages the value of k is not that important.
>>> I can also imagine that at the edge of networks with a strongly
>>> varying
>>> density of repeaters, it is possible that some nodes at the edge only
>>> receive messages with a given regularity when k is infinity.
>>> In the applications that I consider the density of repeaters is quite
>>> homogeneous, the end to end delays are expressed in hundreds of
>>> milliseconds and multiple seeds generate messages on a (tens of)
>>> seconds
>>> scale. In that case k=1 is often excellent and a higher k is not
>>> recommended.
>>> 
>>> hope this helps,
>>> 
>>> peter
>>> 
>>> Don Sturek schreef op 2013-03-29 16:28:
>>>> Hi Kerry,
>>>> 
>>>> Do you have actual test results to back up the claims below?   We
>>>> (the
>>>> ZigBee IP team) tested these parameters among 7 solution providers
>>>> and
>>>> did
>>>> not see what you are reporting.
>>>> 
>>>> Interested in seeing your results.....
>>>> 
>>>> Don
>>>> 
>>>> 
>>>> On 3/29/13 8:08 AM, "Kerry Lynn" <[e-mail]> wrote:
>>>> 
>>>>> On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek <[e-mail]>
>>>>> wrote:
>>>>>> Hi Kerry,
>>>>>> 
>>>>>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses
>>>>>> really
>>>>>> only
>>>>>> occurs in route-over mesh routing.  I don't believe Homenet has
>>>>>> such
>>>>>> routing solutions in their charter.  It is possible to see how a
>>>>>> group
>>>>>> like Manet might use the draft but the only concrete forwarding
>>>>>> solution
>>>>>> proposed is over ROLL RPL instances (certainly, provision was left
>>>>>> in
>>>>>> for
>>>>>> other multicast address usage and attendant forwarding rules but
>>>>>> those
>>>>>> were out of scope for this draft).
>>>>>> 
>>>>> I don't think this opinion reflects on the validity of my comments
>>>>> for
>>>>> even
>>>>> the restricted ROLL use and I'd be interested in feedback from the
>>>>> authors.
>>>>> 
>>>>> In addition to the comments I made previously, I am concerned that
>>>>> the
>>>>> default for Imax (== Imin) prevents the Trickle timer interval I
>>>>> from
>>>>> ever
>>>>> doubling.  Combined with a high k, this leads to aggressive Trickle
>>>>> forwarding
>>>>> in dense parts of the mesh that may inhibit (by interfering with)
>>>>> unicast
>>>>> responses in transit to the original sender.  Is there a reason for
>>>>> not
>>>>> relaxing DATA_MESSAGE_IMAX to e.g.
>>>>> DATA_MESSAGE_TIMER_EXPIRATIONS?
>>>>> 
>>>>> -K-
>>>>> 
>>>>>> I would propose that we move forward with the draft, within ROLL,
>>>>>> and
>>>>>> not
>>>>>> wait for input from other groups since the scope of the initial
>>>>>> draft
>>>>>> (absent extensions that other groups could propose in the future)
>>>>>> is
>>>>>> focused on ROLL RPL.
>>>>>> 
>>>>>> Don
>>>>>> 
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Roll mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll