[6tisch] Early IoT-Dir review of draft-ietf-6tisch-architecture-19

[Eliot Lear <[e-mail]>]

Review type: iotdir - Early review
Requested version for review: Current
Requsted: 2019-02-06
Reviewer: Eliot Lear

Result: On the right track

I propose that this document get another review prior to advancing.

First, the good.

I commend you on using the early review option!  This provides you the opportunity to consider substantial changes prior to garnered consensus, saving you lots of time and energy.

You have much of the content that is necessary to explain the architecture.  In several reads I became confident that much of this will actually work.  Clearly the approach is quite flexible to support a great many deployments.  It seems to me you have identified all the right building blocks.

Major issues

The bad.  It took me several reads over a week to really get it, and I was trying.
This document introduces a great many concepts.  It is not clear to me that they should all be introduced in one document.  As a test, ask yourself this question: what would the reader lose if you did not include Section 4.4.3?  If you are going to introduce all of these concepts, then you need to pay a bit more attention to the organization.  Your hint that you have a problem in this regard is your table of contents: you are spending roughly 12 pages to describe what you label as “High Level Architecture”.  Section 3 needs to be sufficiently succinct that it fits into Section 1.  Otherwise it must be combined into Section 4, which in turn could be broken up into major sections.  I also would have expected something of a mapping between Sections 3 and 4: that is, high level in one, details in the other.  But that’s not really what we get.  Section 3.7 and 3.8 feel as though it really belongs in Section 4.

While there are some illustrations, there are not any examples of how this stuff is intended to function in practice.  I will readily concede that examples are hard to write and get right, but they’re still important, and perhaps nowhere more-so with your AND and OR discussion in Section 4.7.2.  My suggestion is that you seriously consider the validity of any component that you cannot show an example for.  I think visualising schedules in several instances would help, for example.

You have quite a number of groupings and disparate explanations of them.  In this document alone you have cells, slots, slot frames, bundles, tracks, and packets.  These are fundamental to your architecture.  There needs to be a single section that introduces these, and shows how they fit together.  It is not necessary in this introductory session to detail every aspect of these groupings, but simply to show their relationship to one another.  You have a lot of the right diagrams in Sections 3 and 4, but one wants to understand the big picture before delving into the components.

Sections 2.2, 2.3, and 2.4 should be combined and reduced.  Keep in mind that the style of the IETF is to define on first use.  What you want to avoid is the reader having to continuously flip back to the glossary.  People aren’t reading this stuff on paper anymore.  You might think this a minor issue.  However, what you have told me, your dear reader, in Section 2.3 in particular is that I am unlikely to understand this architecture without having a full understanding of a year’s worth of reading, when that’s clearly not the case.

To this end, you should include in your introduction something like Figure 4 that introduces the components.  You might also state some of the operating assumptions of the devices involved, and focus on a few use cases as to how it would be applied (see examples above).
Minor issues
You are referencing BCP 14 but not really using it.  If you are referencing it to explain that you do not mean to be making normative statements, I think it is best to plainly say just that.

In Section 4.6, figures 12, 13, and 14: these diagrams are a bit too abstract. Please add the components and label what is being sent between them.

I realise you probably didn’t originate the term but Join Registrar/Coordinator (JRC) is an odd acronym.  Is this intended to be two architectural components combined into one or just a bit of terminology indecision on the part of the designers ;-)?

In Section 4.2.5, you write:
   In order to ensure that the medium is free of
   contending packets when time comes for a scheduled transmission, a
   window of time is defined around the scheduled transmission where the
   medium must, as much as practcally feasible, be free of contending
   energy.
It is probably worth stating this in terms of whose responsibility it is to find that quiet frequency (thenode’s, right?).  One question this raises is how much energy the node must consume to do that search, the architectural assumption being that it can do so efficiently.

Nits:

There are more nits than these, but this is a start.

Definitions:

Layer-2 vs. Layer 3 bundle:

	a Layer-3 bundle pair maps

s/a Layer-3 bundle pair maps/A Layer-3 bundle maps/

Cell:
	A single element in the TSCH schedule
My suggestion is that you be more explicit: don’t use the word “element”.  Perhaps something like this: “A period of time in the TSCH schedule set aside for data transmission that is identified by…


channelOffset:

Does a channelOffset necessarily imply channel hopping?  What happens if the offset remains constant across a row?

Hard cell:
	A scheduled cell which the 6top sublayer cannot relocate
“Cannot” means it is beyond its means to do so.  I think you mean “may not”.
Track:
Expand DODAG-> Destination Oriented Directed Acyclic Graph

Section 3.6, 1st para:
	This architecture requires work to standardize the the
s/the the/the/

Section 4.1

First para, s/Root/root/, as used in RFC 6550.

Section 4.2:
   As a result of the process of chunk ownership appropriation, the RPL
   parent has exclusive authority to decide which cell in the
   appropriated chunk can be used by which node in its interference
   domain.  In other words, it is implicitly delegated the right to
   manage the portion of the CDU matrix that is represented by the
   chunk.  The RPL parent may thus orchestrate which transmissions occur
   in any of the cells in the chunk, by allocating cells from the chunk
   to any form of communication (unicast, multicast) in any direction
   between itself and its children.

This twice-redundant.  I can understand reinforcing the point.  My suggestion: drop the last sentence.

Section 4.5.5:

Formatting issues.  If you are quoting text, please source your quote.  Otherwise, do not indent.  Also...
      In one hand, a
Just remove that.
Same para below:
	It results that a frame
s/It results that a frame/It results in a frame/
Section 4.7.2:
This sentence does not parse:
   As it goes, 6TiSCH expects that timeslots corresponding to copies of
   a same packet along a Track are correlated by configuration, and does
   not need to process the sequence numbers.
Who does not need to process sequence #s?  Be specific.
   The semantics of the configuration will enable correlated timeslots
   to be grouped for transmit (and respectively receive) with a 'OR'
   relations, and then a 'AND' relation would be configurable between
   groups.
s/with a ‘OR’/with an ‘OR’/
s/with a ‘AND’/with an ‘AND’/
   The 'OR' relation
   indicates that if a transmission is acknowledged, then further
   transmissions should not be attempted for timeslots in that group.
s/acknowledged, then further transmissions/acknowledged.  In this case,/