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

Mališa Vučinić <> Thu, 04 April 2019 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 940F91201DE; Thu, 4 Apr 2019 10:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.92
X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gZOr_J_B_6Pu; Thu, 4 Apr 2019 10:33:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A94B21201CF; Thu, 4 Apr 2019 10:33:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="scan'208,217";a="377247363"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 19:33:01 +0200
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2FD4BAB6-F8FB-43E4-99C5-662B8C40A066"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 4 Apr 2019 19:33:01 +0200
In-Reply-To: <10538.1554392453@localhost>
Cc: Marco Tiloca <>, 6tisch <>,
To: Michael Richardson <>
References: <5427.1554253601@localhost> <> <8081.1554386670@localhost> <> <10538.1554392453@localhost>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Apr 2019 17:33:07 -0000

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.


> On 4 Apr 2019, at 17:40, Michael Richardson <> wrote:
> Can you see how the old/new key issue interacts poorly with the permuted
> schedule?