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

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 04 April 2019 17:33 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940F91201DE; Thu, 4 Apr 2019 10:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.92
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZOr_J_B_6Pu; Thu, 4 Apr 2019 10:33:04 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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 wifi-pro-83-027.paris.inria.fr ([128.93.83.27]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 19:33:01 +0200
From: Mališa Vučinić <malisa.vucinic@inria.fr>
Message-Id: <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr>
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, 04 Apr 2019 19:33:01 +0200
In-Reply-To: <10538.1554392453@localhost>
Cc: Marco Tiloca <marco.tiloca@ri.se>, 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org
To: Michael Richardson <mcr@sandelman.ca>
References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <B222C2F7-084F-4CBA-A55D-720619058D38@inria.fr> <10538.1554392453@localhost>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/9t8flSJSN2HiHYhGvjMrZT-uy0U>
Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key
X-BeenThere: 6tisch@ietf.org
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=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.

Mališa


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