Hi Tengfei, Thanks for these questions.
1. We're not protecting against selective jamming on the minimal cell indeed. This is a tricky problem, because beacons must include enough information for nodes to find out when to tx/rx for the join procedure, and a not-joined-yet node can do it then so can an attacker. Our threat model is where the attacker is interested in degrading the performance for a given [set of] node[s] in a running network. 2. This is a great point. We currently know of two approaches, both of which involve a slight modification of MSF. (a) make MSF use the minimal cell instead of autonomous for joining or (b) move autonomous cells to a different slotframe than dedicated cells (e.g. to autonomous to slotframe 0, or dedicated to a new slotframe 2). Best, Simon On Thu, Apr 4, 2019 at 6:47 PM Tengfei Chang <[email protected]> wrote: > Hello Authors, > > I just reviewed the draft. It reads pretty good for me! I only found a > tiny typo error in Eq.1 where the 'c' is not defined actually, I believe > you mean 'chOff'. > > Besides, I have two questions referring the usage of minimal cell. > > 1. What if the selective jamming applied on the minimal cell? Do you > consider to resolve this case? > > 2. The joining traffic is going on minimal cell in slotframe 0. Do you > plan to use some strategy to regulate the traffic on minimal cell? I am > asking this because this is different from what MSF is doing, which send > joining packet over autonomous cell. > > Tengfei > > -- > Chang Tengfei, > Pre-Postdoctoral Research Engineer, Inria > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
