Re: [6tisch] Comments on draft-chang-6tisch-msf-00

Thomas Watteyne <thomas.watteyne@inria.fr> Thu, 01 March 2018 16:31 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 5CCBC12EB19 for <6tisch@ietfa.amsl.com>; Thu, 1 Mar 2018 08:31:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 RyhqGEM77hsE for <6tisch@ietfa.amsl.com>; Thu, 1 Mar 2018 08:31:37 -0800 (PST)
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 C922B12EB08 for <6tisch@ietf.org>; Thu, 1 Mar 2018 08:31:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.47,408,1515452400"; d="scan'208,217";a="256611082"
Received: from mail-vk0-f51.google.com ([209.85.213.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 01 Mar 2018 17:31:34 +0100
Received: by mail-vk0-f51.google.com with SMTP id p189so4020280vkd.10 for <6tisch@ietf.org>; Thu, 01 Mar 2018 08:31:34 -0800 (PST)
X-Gm-Message-State: APf1xPCykXboeN6pTXAHEvkEQxH9AaOuPE16/NEYy9hrsQ5XgJ8HU9bC P9hdcBN2VsulyNdk1h0klJYBwQ92AKSExIiRp88=
X-Google-Smtp-Source: AG47ELvYg3Yk4fycL+12mpxnYH588lVDCmU6QzhkW394jB5YA1NeK/uLyGIoaOpKjsMVHusmfY62ODJ8qVe6e3+Bz3w=
X-Received: by 10.31.205.5 with SMTP id d5mr1648232vkg.50.1519921893413; Thu, 01 Mar 2018 08:31:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.112.21 with HTTP; Thu, 1 Mar 2018 08:31:12 -0800 (PST)
In-Reply-To: <CAC9+vPgBSR0KdAAxionzShrf_1E2rL5SbwuK7J-vZDt14MdK-g@mail.gmail.com>
References: <1773604737.157154.1518542023636.JavaMail.root@canet.uoc.es> <CAC9+vPgBSR0KdAAxionzShrf_1E2rL5SbwuK7J-vZDt14MdK-g@mail.gmail.com>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Thu, 1 Mar 2018 17:31:12 +0100
X-Gmail-Original-Message-ID: <CADJ9OA9Kg-Mzbe3a6Hu4a64C7xVKWUPPCsHVe572cy4+3bEBGw@mail.gmail.com>
Message-ID: <CADJ9OA9Kg-Mzbe3a6Hu4a64C7xVKWUPPCsHVe572cy4+3bEBGw@mail.gmail.com>
To: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="001a114ddbb28b1b5c05665c64dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/fA7yP1x_0v7htSn6U0eQa9S7mk4>
Subject: Re: [6tisch] Comments on draft-chang-6tisch-msf-00
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Mar 2018 16:31:40 -0000

Yatch,

About :

*Why does the node have to issue a 6P CLEAR to a neighbor which is
determined to be unreachable...? It just wastes time and energy of the
initiator since this transaction will fail as the draft mentioned. I think
it'd be fine to remove all the dedicated cells to the unreachable neighbor
without 6P CLEAR. By the way, the term "cells" should be used instead of
"links".*

I would recommend to use a MAY in this case. That is, a node MUST remove
cells, and MAY send a CLEAR.

Thomas


On Wed, Feb 14, 2018 at 5:28 AM, Xavi Vilajosana Guillen <
xvilajosana@uoc.edu> wrote:

> Dear Yatch,
>
> thanks for your comments! see inline my answers.
>
> 2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>:
>
>> Hi all,
>>
>> I'd like to share my comments on draft-chang-6tisch-msf-00:
>>
>>    https://tools.ietf.org/html/draft-chang-6tisch-msf-00
>>
>> The first one is about 6P CLEAR after detecting unreachability to a
>> neighbor.
>>
>> > 3.8.  Step 7 - Neighbor Polling
>> >
>> > (snip)
>> >
>> >    When a neighbor is declared unreachable, the node MUST issue a 6P
>> >    CLEAR to that neighbor (which can fail at the link-layer), and MUST
>> >    remove all dedicated links with that neighbor from its own schedule.
>>
>>
>> Why does the node have to issue a 6P CLEAR to a neighbor which is
>> determined to be unreachable...? It just wastes time and energy of the
>> initiator since this transaction will fail as the draft mentioned. I think
>> it'd be fine to remove all the dedicated cells to the unreachable neighbor
>> without 6P CLEAR. By the way, the term "cells" should be used instead of
>> "links".
>>
>>
> XV> I agree. A node can directly reset its schedule. We will change that
> sentence.
>
>
>> Other comments are trivial.
>>
>> > 1.  Introduction
>> >
>> > (snip)
>> >
>> >    MSF is designed to operate in a wide range of application domains.
>> >    It is optimized for applications with regular upstream traffic (from
>> >    the nodes to the Internet).
>>
>> "The internet" sounds too specific. "From the nodes toward the root"
>> would be better?
>>
>
> XV>> Agree.
>
>>
>> > 2.  Interface to the Minimal 6TiSCH Configuration
>> >
>> > (snip)
>> >
>> >    MSF uses the minimal cell to exchange the following packets:
>> >
>> > ...
>> >
>> >    4.  The first 6P packet a node issues to a neighbor it doesn't have
>> >        dedicated cells to, as defined by
>> >        [I-D.ietf-6tisch-6top-protocol].  These are unicast frames.
>>
>> The minimal cell is used for not only the first 6P packet but also
>> subsequent packets associated with a 6P transaction initiated by the first
>> packet. In this sense, I'd like to propose to replace it with:
>>
>>    6P packets to schedule the first dedicated cell with a neighbor. There
>> are unicast frames.
>>
>
> XV>> Agree.
>
>>
>> > 7.  Rules for CellList
>> >
>> >
>> >    MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
>> >    only initiated by a node towards it preferred parent.  As a result,
>> >    the cells to put in the CellList of a 6P ADD command, and in the
>> >    candidate CellList of a RELOCATE command, are chosen by the node.  In
>> >    both cases, the same rules apply:
>> >
>> >       the CellList SHOULD contain 5 or more cells.
>> >       Each cell in the CellList MUST have a different slotOffset value.
>> >       For each cell in the CellList, the node MUST NOT have any
>> >       scheduled cell on the same slotOffset.
>> >       The slotOffset value of any cell in the CellList MUST NOT be the
>> >       same as the slotOffset of the minimal cell (slotOffset=0).
>> >       The slotOffset of a cell in the CellList SHOULD be randomly and
>> >       uniformly chosen among all the slotOffset values that satisfy the
>> >       restriction above.
>> >       The channelOffset of a cell in the CellList SHOULD be randomly and
>> >       uniformly in [0..numFrequencies] where numFrequencies represents
>> >       the number of frequencies a node can communicate on.
>>
>>
>> Is this a format error...?
>>
>
> XV>> No, I think this is a bullet list with "invisible" bullets :) . We
> add the bullets.
>
>>
>> > 8.  6P Timeout Value
>> >
>> >
>> >    The 6P Timeout is not a constant value.  It is calculated a (C/
>> >    PDR)*6PTIMEOUT_SEC_FACTOR, where:
>>
>>
>> I think it'd be better for a variable name to start with a non-numeric
>> character even in a document.
>>
>>
> XV>> Agree.
>
>
>> That's it!
>>
>> Best,
>> Yatch
>>
>
> thanks Yatch!
> regards
> X
>
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> xvilajosana@uoc.edu <usuari@uoc.edu>
> http://xvilajosana.org
> http://wine.rdi.uoc.edu
> Parc Mediterrani de la Tecnologia
> Av Carl Friedrich Gauss 5, B3 Building
> 08860 Castelldefels (Barcelona). Catalonia. Spain
> [image: Universitat Oberta de Catalunya]
> ­
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
________________________________________

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

www.thomaswatteyne.com
________________________________________