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> 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
