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

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 24 Aug 2018 13:51:37 +0200

Hi authors,

Congratulations on this great work!

  https://tools.ietf.org/html/draft-ietf-6tisch-msf-00

I'm sharing my comments on the draft; major comments are followed by minor
comments.

* discussion: when to schedule autonomous TX cells to neighbors

According to Section 4, a join proxy (JP) needs to schedule an autonomous TX
cell to a node (pledge) who wants to join the network. Thanks to this, a join
process can be done with the autonomous cells of the JP and pledge. These
autonomous cells make the network formation faster.

However, from the view point of security, it'd be better to avoid installing any
state for an unauthenticated/unauthorized node. In this particular case, the
join proxy shouldn't schedule the autonomous cell to the pledge.

We would need some discussion in "Security Considerations" section if we allow
JPs to install autonomous TX cells to their pledges.

* question: why do we need a separate slotframe for MSF?

MSF avoids using slot offset 0 for its autonomous cells and its dedicated cells
anyway. The length of Slotframe 1 for MSF is the same as Slotframe 0

draft> (Section 3)
draft> As detailed in Section 2.2 of [I-D.ietf-6tisch-6top-protocol], MSF MUST
draft> schedule cells from Slotframe 1, while Slotframe 0 is used for traffic
draft> defined in the Minimal 6TiSCH Configuration.
draft> (...)
draft> The first time offset is skipped to avoid colliding with the minimal cell
draft> in Slotframe 0.

draft> 8.  Rules for CellList
draft> 
draft> (snip)
draft>    o  The slotOffset value of any cell in the CellList MUST NOT be the
draft>       same as the slotOffset of the minimal cell (slotOffset=0).

* question: parameters for SAX

What values are used for L and R in SAX? It'd be nice to have an example or a
test vector in the draft in order to validate a SAX implementation used for
MSF. This is critical for interoperability.

* minor comment 1

draft> (Section 1)
draft> The end state of the join process is that the node is synchronized to the
draft> network, has mutually authenticated to the network, has identified a
draft> preferred routing parent, has scheduled one default unicast cell to/from
draft> each of its neighbors.

The latter part of this sentence seems not to be accurate.

After the join process, the node (pledge) has the following cells:

- the minimal cell defined by RFC 8180
- one autonomous RX cell
- autonomous TX cells to its JP

This doesn't fit "one default unicast cell to/from each of its neighbors."

* minor comment 2

draft> (Section 2)
draft> A node implementing MSF MUST implement the Minimal 6TiSCH Configuration
draft> [RFC8180], which defines the "minimal cell", a single shared cell
draft> providing minimal connectivity between the nodes in the network.

'MUST' here sounds too strong... Some may want to use MSF with a base schedule
other than one defined RFC 8180 with full understands on implications by not
following RFC 8180. Then, I'd propose 'SHOULD'.

By the way, I'm not sure whether we can specify 'MUST implement' to a BCP
document or not.

* minor comment 3

draft> (Section 2)
draft> 2.  DODAG Information Objects (DIOs), defined by [RFC6550].  These are
draft> broadcast frames.

A DIO can be sent in a unicast frame.

rfc6550> 8.3.  DIO Transmission
rfc6550> (...)
rfc6550> When a node receives a unicast DIS message with a Solicited Information
rfc6550> option and matches the predicates of that Solicited Information option,
rfc6550> it MUST unicast a DIO to the sender in response.

So, that sentence could be...

       2.  DODAG Information Objects (DIOs), defined by [RFC6550].  Broadcasted
       DIOs are sent over the minimal cell.

Or, it would be fine to say just "broadcast frames are (always) sent in the
minimal cell", although there is text which doesn't agree with this proposal:

draft> 5.1.  Adapting to Traffic
draft> (...)
draft> Autonomous cells are used indistinguishably together with dedicated
draft> cells, for broadcast or unicast traffic with the target neighbor.

* minor comment 4

The following part seems to me an implementation-specific optimization. And it
is beyond of the scope of this draft. Basically, this idea is about how to use
the minimal cell efficiently; it's not directly related to how to use cells
scheduled by MSF.

draft> (Section 2)
draft> Because the minimal cell is SHARED, the back-off algorithm defined in
draft> [IEEE802154-2015] is used to resolve collisions.  To ensure there is
draft> enough bandwidth available on the minimal cell, a node implementing MSF
draft> SHOULD enforce the following rules for broadcast frames:
draft> ...

* minor comment 5

The phrase of "After joining" in the explanation of step 3 should be "After
deciding a JP to use"? At this step 3, "joining" is not done.

draft> (Section 4)
draft> 4.4.  Step 3 - Setting up Autonomous Unicast Cells
draft> 
draft>    After joining, nodes MUST set up their autonomous unicast cells, as
draft>    described in Section 3.  This enables unicast communication in
draft>    Slotframe 1, until more cells are added with 6P as defined in
draft>    Section 5.
draft> 
draft> 4.5.  Step 4 - Join Request/Response

* minor comment 6

What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
section?

That's all!

Best,
Yatch

---

From: Simon Duquennoy <[email-masked]>
Date: Fri, 31 Aug 2018 10:26:47 +0200

> JPs to install autonomous TX cells to their pledges.

I fully agree this needs further discussion. In the worst case we might
have to move back the join traffic to the minimal cell, yes.

> draft>       same as the slotOffset of the minimal cell (slotOffset=0).

The draft currently says the slotframes SHOULD (not MUST) have the same
value.
The rationale for allowing different value is to have more flexible
dimensioning, and better adjust to more broadcast-intensive or
unicast-intensive networks.

> MSF. This is critical for interoperability.

Thanks for pointing out, will fix in next version.

> This doesn't fit "one default unicast cell to/from each of its neighbors."

Got it, thanks.

> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP

MSF assumes the presence of the minimal cell, but might be able to run
without the full RFC8180.
Happy to hear what others think

> draft> cells, for broadcast or unicast traffic with the target neighbor.

Agree, I think we should simply send all broadcast to the minimal cell.

> draft> SHOULD enforce the following rules for broadcast frames:

I'll let other co-authors answer on that one

> draft> 4.5.  Step 4 - Join Request/Response

Good catch, will fix in next version

> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this

I'll let other co-authors answer

> That's all!

Thanks a lot Yatch!
Simon

>
> Best,
> Yatch
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 31 Aug 2018 14:53:45 +0200

Hi Yatch, thanks so much for the review.

I jump in complementing Simon´s answer.

Missatge de Simon Duquennoy <[email-masked]> del dia dv., 31 d’ag.

> Happy to hear what others think

XV>> MSF needs at least one pre-existing cell in the schedule so a node can
receive/send EBs and form/join into the network. To ensure this we enforce
RFC8180. I think that if someone else implements any other policy there
won't be conflict with the existence of a minimal cell as RFC8180 only
recommends default values which can be overriden.

> I'll let other co-authors answer on that one

XV> here we place a SHOULD and not a MUST. We want to make sure the network
works as if there is over-use of the minimal cell collapses. We think this
should be said here so an adopter is aware of the limitations and
implements a working measure.

>> deciding a JP to use"? At this step 3, "joining" is not done..
>>
>> draft> (Section 4)

XV> I think this was though to handle pagination when the LIST command is
received. This is, define what are the cells to return when a list command
is requesting cells from a particular offset.

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

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 31 Aug 2018 15:33:38 +0200

Thank you, Simon and Xavi!

A couple of things:

>> MSF assumes the presence of the minimal cell, but might be able to run without the full RFC8180.
> XV>> MSF needs at least one pre-existing cell in the schedule so a node can receive/send EBs and form/join into the network. To ensure this we enforce RFC8180.

If the minimal shared cell is only the dependency for MSF, it'd be much clearer to say that instead of saying, "MSF MUST implement RFC 8180". RFC 8180 defines far more things than having the minimal shared cell. And, it concerns 2.4 GHz O-QPSK PHY alone.

> XV> I think this was though to handle pagination when the LIST command is received. This is, define what are the cells to return when a list command is requesting cells from a particular offset. 

I see; then, I'd like to have such explanation in Section 10 :-)

   https://tools.ietf.org/html/draft-ietf-6tisch-msf-00#section-10

Best,
Yatch