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

[Yusuke DOI <[e-mail]>]

Hi Peter,

Thank you for sharing your scenario and parameters. Could you tell me how did you selected the parameters?
I have following two scenarios... and considering how MPL works on the cases.

Scenario A  (commanding)
1) maybe up to 30 neighbours
2) a few/hour
3) end-to-end 5 seconds, 500ms per hop
4) up to 10 hops
5) not sure
6) many, including multiple threads of Scenario B
7) not sure (80%?)

Scenario B (file transfer)
1) maybe up to 30 neighbors
2) 25 packets / hour
3) no deadline per packet
4) up to 10 hops
5) not sure
6) multiple threads of Scenario B and many other traffics
7) not sure (80%?)

Regards,

Yusuke


(2013-09-17 19:21), peter van der Stok wrote:
> Hi Michael,
> corresponding questions can be:
>
> 1) What are the maximum and minimum 1-hop MPL router neighbours of all the MPL routers?
> 2) what is the arrival rate of new packets that need repetition in a MPL router
> 3) Is there a deadline associated with the packets
> 4) What is the shortest number of hops of the longest path between sources and destinations
> 5) What are the values of the MAC: back-off values, retries, buffer size.
> 6) What is the background load of other non MPL applications.
> 7) arrival probability of 1-hop packets
> 8) other parameters I did not stumble on.
>
> The corresponding design space is incredibly large, and probably only a limited subset of the design space is viable.
> I have gone through only a limited number of possibilities, and analysing the consequences for MPL took me quite a large amount of time.
>
> In one of my scenarios:
> 1) 5 neighbours
> 2) once every 100 ms (rate at sources is once every 300-500 ms)
> 3) yes, 200 ms
> 4) 5 hops, with mostly 1 hop
> 5) no buffer, retry 1, back-off 2
> 6) absent
> 7) 100-80%
>
> leading to k=3-5, Imin =30-70 ms, repeat = 2, Imax n/a.
>
> It may help that operational boundary conditions together with appropriate MPL parameter values are published in the applicability statements.
> All applicability statements together may give a good hint which MPL parameters and boundary conditions to choose.
>
> My 5 cents,
>
> peter
>
>
>
>
>
> Michael Richardson schreef op 2013-09-16 17:15:
>> peter van der Stok <[e-mail]> wrote:
>> >> 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.
>>
>> peter> After looking for an appropriate setting for Imin, Imax and k, I
>> peter> slowly learnt that these settings depend on the topology of the
>> peter> network, the load of the network, the setting of the MAC, and
>> peter> eventual real-time requirements (e.g. there is a deadline), and
>> peter> the value of that deadline.  The setting of k for example is
>> peter> related to the number of MPL repeaters that receive a new message
>> peter> and start to resend it, possibly interfering with each other and
>> peter> probably incrementing the c value of the next hop, where the
>> peter> maximum value of c is related to the Imin value.  Sending a packet
>> peter> takes as little as 3 ms, but when the MAC stores three packets and
>> peter> the they all back-off a maximum number of times, delays of a few
>> peter> hundred milliseconds to seconds become possible.  When there is
>> peter> buffer space for packets before and in the MAC, the Imin value can
>> peter> be chosen as low as 1 ms, the resend of packets is then completely
>> peter> determined by the load on the network.
>>
>> This is an excellent template discussion... can I put it into the MPL
>> parameter part of the RPL applicability template?
>>
>> Do you think you could rephrase this in the form of questions to be
>> answered?
>>
>> --
>> 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