Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

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.vucinic@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 <mcr@sandelman.ca <mailto:mcr@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