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,/
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
