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

From: Thomas Watteyne <[email-masked]>
Date: Thu, 1 Mar 2018 17:31:12 +0100

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 <
[email-masked]> wrote:

> Dear Yatch,
>
> thanks for your comments! see inline my answers.
>
> 2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka <[email-masked]>:
>
>> 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
>> [email-masked]
>> 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>
> [email-masked] <[email-masked]>
> 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
> 
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> 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
________________________________________

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 1 Mar 2018 17:35:11 +0100

Hi Thomas, Xavi,

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

That sounds good to me!

Best,
Yatch