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

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 13 Feb 2018 18:13:04 +0100

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".

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?

> 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.

> 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...?

> 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.

That's it!

Best,
Yatch

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Wed, 14 Feb 2018 05:28:41 +0100

Dear Yatch,

thanks for your comments! see inline my answers.

2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka <[email-masked]>:

> 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.

> "The internet" sounds too specific. "From the nodes toward the root" would

XV>> Agree.

> 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:
>

XV>> Agree.

> Is this a format error...?

XV>> No, I think this is a bullet list with "invisible" bullets :) . We add
the bullets.

> character even in a document.
XV>> Agree.

> 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
[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