Dear Yatch,

thanks for your comments! see inline my answers.

2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka <yasuyuki.tan...@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
xvilajos...@uoc.edu <usu...@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

Reply via email to