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

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

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