Re: [6tisch] The channel hopping scheme seems to be suboptimal

Thomas Watteyne <thomas.watteyne@inria.fr> Fri, 23 September 2016 06:43 UTC

Return-Path: <thomas.watteyne@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 F04E112B1D7 for <6tisch@ietfa.amsl.com>; Thu, 22 Sep 2016 23:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.715
X-Spam-Level:
X-Spam-Status: No, score=-8.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316] 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 EMXtAPcgnYNz for <6tisch@ietfa.amsl.com>; Thu, 22 Sep 2016 23:43:43 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 B05CE12B33D for <6tisch@ietf.org>; Thu, 22 Sep 2016 23:43:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,380,1470693600"; d="scan'208,217";a="194381964"
Received: from mail-wm0-f44.google.com ([74.125.82.44]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 23 Sep 2016 08:43:40 +0200
Received: by mail-wm0-f44.google.com with SMTP id l132so12210421wmf.0 for <6tisch@ietf.org>; Thu, 22 Sep 2016 23:43:40 -0700 (PDT)
X-Gm-Message-State: AA6/9RmvxiQ6VKIwqVBiyTJzu6LaYI7rmjLvwgZwwNko4n04Pv+/kmJa/T+mBhsyZlWpJ9jLPNicIhOGaWS+/w==
X-Received: by 10.28.87.16 with SMTP id l16mr1064450wmb.75.1474613020222; Thu, 22 Sep 2016 23:43:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.173.135 with HTTP; Thu, 22 Sep 2016 23:43:19 -0700 (PDT)
In-Reply-To: <87bmzgf16w.fsf@hobgoblin.ariadne.com>
References: <87bmzgf16w.fsf@hobgoblin.ariadne.com>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Fri, 23 Sep 2016 08:43:19 +0200
X-Gmail-Original-Message-ID: <CADJ9OA_B_fGy3xu3Fr_zWDuxcdP1-3bx7j6DA3pxoUgXpJ3QAA@mail.gmail.com>
Message-ID: <CADJ9OA_B_fGy3xu3Fr_zWDuxcdP1-3bx7j6DA3pxoUgXpJ3QAA@mail.gmail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Content-Type: multipart/alternative; boundary="001a1144375a406cd9053d2719ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/3XFJidIwAHvlFfx9r7zwHytwLt8>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] The channel hopping scheme seems to be suboptimal
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 23 Sep 2016 06:43:46 -0000

Dale,

Please note that RFC7554 is informational, and describes/introduces the
functioning of TSCH. The actual standard is IEEE802.15.4-2015 [1]. In
particular, in case of discrepencies between the docs, IEEE802.15.4-2015 is
the one to follow.

You raise a valid point. There are a couple of points, though, that make an
"Absolute Slot Number" more favorable compared to an "Absolute Slotframe
Number":
- if you schedule multiple cells between two nodes in a single slotframe,
you want those different transmissions to happen at a different frequency
- ASN is used to construct a nonce when securing link-layer frames.
Security is such that we never want to re-use the same nonce.

Happy to answer further questions to might have, also during the interim
meeting later today [2].

Thomas

[1] http://standards.ieee.org/about/get/802/802.15.html
[2] https://www.ietf.org/mail-archive/web/6tisch/current/msg04760.html

On Thu, Sep 22, 2016 at 4:39 PM, Dale R. Worley <worley@ariadne.com> wrote:

> Pardon me, I'm new here, but I was wondering why the channel hopping
> scheme is defined the way it is.  Currently, RFC 7554 notes that the
> channel selected for a transmission by a node is:
>
>    frequency = frequency_table [ (ASN + channelOffset) mod nFreq ]
>
> where channelOffset is a set value for this node to use in this slot of
> the slotframe cycle, frequency_table is a set array of frequencies, and
> nFreq is the size of frequency_table.
>
> The question I have is with ASN, the "absolute slot number".  RFC 7554
> states that it increments one for each slot time, so that as a
> particular slotframe slot recurs, the ASN is incremented by the number
> of slots in the slotframe.
>
> The result is that to ensure that each node's transmissions cycle
> through all the frequencies in the frequency_table, the length of the
> slotframe needs to be relatively prime to nFreq:
>
>    A way of ensuring communication happens on all available frequencies
>    is to set the number of timeslots in a slotframe to a prime number.
>
> My question is that if ASN was redefined to be a counter of slotframes
> rather than of slots, then each node would cycle through all the
> frequencies regardless of the size of the slotframe, because each node's
> frequency index would advance 1 with each slotframe rather than
> (slotframe_size mod nFreq).
>
> This alternative is fairly obvious, so there must be a known reason why
> it isn't desirable.
>
> Dale
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>



-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________