It seems i have permuted slotOffset and channelOffset below :-) This may be a 
piste if slotOffset permutation is kept but there would likely be problems for 
nodes with higher bandwidth requirements and many cells in the schedule to 
guarantee zero slotOffset collisions in one own’s schedule across slotframe 
iterations. Don’t really like it though for the reason of breaking the 
scheduling function.

As a reminder, in minimal-security we resorted to the current rekeying 
mechanism and not the one using the exact timestamp in the future when the 
whole network switches to new keys in order to avoid having to know the network 
notion of time at the JRC.

Mališa

> On 4 Apr 2019, at 19:33, Mališa Vučinić <malisa.vuci...@inria.fr> wrote:
> 
> My understanding is that the problem in the permuted schedule arises during 
> COJP_REKEYING_GUARD_TIME after nodes in the network started using the new 
> keys, but have still kept the old key in case someone has not yet switched. 
> When coupled with a rekeyed permutation key to calculate the schedule, this 
> means that during COJP_REKEYING_GUARD_TIME a node would need to follow two 
> schedules, one with the old permutation key and one with the new one. The 
> problem in following two schedules for COJP_REKEYING_GUARD_TIME is that 
> draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset and 
> the channelOffset be permuted so that it may occur that there can be a 
> collision in slotOffset between the new and the old schedule.
> 
> The problem that draft-tiloca-6tisch-robust-scheduling solves seems to be the 
> predictability of the channel on which a transmission is going to take place. 
> With that in mind, I have second thoughts about the recommendation on 
> permuting the slotOffset, especially taking into account that this will break 
> any scheduling function that optimizes for latency, as discussed in Section 
> 6.3.
> 
> Mališa
> 
> 
>> On 4 Apr 2019, at 17:40, Michael Richardson <m...@sandelman.ca 
>> <mailto:m...@sandelman.ca>> wrote:
>> 
>> Can you see how the old/new key issue interacts poorly with the permuted
>> schedule?
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to