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

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

Hi Yusuke,

thanks for your interest.
I got the parameter values by doing an on-paper analysis of the 
propagation patterns and the synchrony between the copies sent by 
multiple repeaters
In combination with many simulations, I finally understood what went on 
and came up with a motivated set of parameter values.
The use cases themselves were motivated by run of the mill lighting 
office installations.

For other use cases this process will be faster though.

For your case it would take some simulation try-outs (few days) to get 
it right.
The 30 neighbours makes me think that you need a k value of 10 or 
higher, dependent how the propagation proceeds to the borders of the 
network.
25 packets /hour remove too many worries about interference.
Probably a max repeat of 2 will be sufficient. I usually make the source 
a repeater as well to make sure that one packet arrives at least at one 
destination.
Probably a short Imin value like 30-70 ms will do for you as well; and 
then you will certainly meet the deadlines.
When you have bursts of packets at a repeater, say 10 within 50 ms, 
interference becomes important, and the behaviour of the MAC comes into 
play, retarding the packets and threatening the meeting of the deadline.

But again, It would take a more thorough analysis to come up with 
numbers which can be taken seriously.

Greetings,

Peter


Yusuke DOI schreef op 2013-09-17 12:56:
> 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