Subject: [6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01

From: Tengfei Chang <[email-masked]>
Date: Thu, 4 Apr 2019 18:46:43 +0200

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

---

From: Simon Duquennoy <[email-masked]>
Date: Thu, 4 Apr 2019 20:57:21 +0200

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-masked]>
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'.
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 5 Apr 2019 10:19:01 +0200

Hello Tengfei,

Thank you for your review!

As to your comment on Equation 1, we used 'c' to highlight it as the
unknown variable when solving the equation, but indeed it refers to the
channel offset. We will make this explicit in the text.

Best,
/Marco

On 4/4/19 8:57 PM, Simon Duquennoy wrote:
> 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.
>
> 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-masked]
> <mailto:[email-masked]>> 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'.
>
>     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,
>     [email-masked] <mailto:[email-masked]>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Simon Duquennoy <[email-masked]>
Date: Thu, 4 Apr 2019 20:54:39 +0200

Hi Tengfei,

Best,
Simon