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

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Eliot and all:

For the AND/OR discussion, I propose the following example:

  As an example say that we have a simple network as represented in
   Figure 17, and we want to enable PREOF between an ingress node I and
   an egress node E.

                              +-+         +-+
                           -- |A|  ------ |C| --
                         /    +-+         +-+    \
                       /                           \
                  +-+                                +-+
                  |I|                                |E|
                  +-+                                +-+
                       \                           /
                         \    +-+         +-+    /
                           -- |B| ------- |D| --
                              +-+         +-+

              Figure 17: Scheduling PREOF on a Simple Network

   The assumption for this particular problem is that a 6TiSCH node has
   a single radio, so it cannot perform 2 receive and/or transmit
   operations at the same time, even on 2 different channels.

   Say we have 6 possible channels, and at least 10 timeslots per
   slotframe.  Figure 18 shows a possible schedule whereby each
   transmission is retried 2 or 3 times, and redundant copies are
   forwarded in parallel via A and C on the one hand, and B and D on the
   other, providing time diversity, spatial diversity though different
   physical paths, and frequency diversity.

                    +----+----+----+----+----+----+----+----+----+
    channelOffset 0 |    |    |    |    |    |    |B->D|    |    | ...
                    +----+----+----+----+----+----+----+----+----+
    channelOffset 1 |    |I->A|    |A->C|B->D|    |    |    |    | ...
                    +----+----+----+----+----+----+----+----+----+
    channelOffset 2 |I->A|    |    |I->B|    |C->E|    |D->E|    | ...
                    +----+----+----+----+----+----+----+----+----+
    channelOffset 3 |    |    |    |    |A->C|    |    |    |    | ...
                    +----+----+----+----+----+----+----+----+----+
    channelOffset 4 |    |    |I->B|    |    |B->D|    |    |D->E| ...
                    +----+----+----+----+----+----+----+----+----+
    channelOffset 5 |    |    |A->C|    |    |    |C->E|    |    | ...
                    +----+----+----+----+----+----+----+----+----+
       slotOffset      0    1    2    3    4    5    6    7    9


                    Figure 18: Example Global Schedule

   This translates in a different slotframe for every node that provides
   the waking and sleeping times, and the channelOffset to be used when
   awake.  Figure 19 shows the corresponding slotframe for node A.


                    +----+----+----+----+----+----+----+----+----+
    channelOffset   |CO 2|CO 1|CO 5|CO 1|CO 3|    |    |    |    | ...
                    +----+----+----+----+----+----+----+----+----+
       slotOffset      0    1    2    3    4    5    6    7    9


                    Figure 19: Example Node A slotframe

   In that example, the logical relationship between the timeslots is:


               +------+---------------------+------------------------+
               | Node |    rcv slotOffset   |    xmit slotOffset     |
               +------+---------------------+------------------------+
               | I    |         N/A         | (0 OR 1) AND (2 OR 3)  |
               | A    |       (0 OR 1)      |     (2 OR 3 OR 4)      |
               | B    |       (2 OR 3)      |     (4 OR 5 OR 6)      |
               | C    |    (2 OR 3 OR 4)    |        (5 OR 6)        |
               | D    |    (4 OR 5 OR 6)    |        (7 OR 8)        |
               | E    |  (5 OR 6 OR 7 OR 8) |          N/A           |
               +------+---------------------+------------------------+


                      Figure 20: Logical Relationship



All the best,

Pascal

From: Pascal Thubert (pthubert)
Sent: mardi 26 février 2019 15:08
To: 'Eliot Lear' <[e-mail]>; iot-dir <[e-mail]>; [e-mail]; [e-mail]; Suresh Krishnan <[e-mail]>
Cc: Carlos Pignataro (cpignata) <[e-mail]>; CARLOS JESUS BERNARDOS CANO <[e-mail]>
Subject: RE: Early IoT-Dir review of draft-ietf-6tisch-architecture-19

Hello Eliot

Many thanks for your early review! And yes, I agree that a smaller committee is great to clean up the major aspects before opening to the wider public.

Please see below (in purple in the text):

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.


Ø   Yes, and we have built it (2 open source plus a major private implementations) and interop tested it (with ETSI) over the recent years : )

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.

     *   Section 4.4.3 positions the future work at PAW. This is what enables the “deterministic thing” and is the major mode of operation in the pre-6tisch art of process control network. We could not really ignore it. The split with a high level architecture is a result of a review by Ralph long ago. Ralph expected a succinct high level architecture and the doc with section 3 and 4 as one was too deep and wide. I agree with you that 3.7 and 3.8 could move to section 4, this would reduce section 3 down to 8 pages and get us closer to what Ralph expected I guess.
     *   The outlook of the ToC would then be:
   2.  Terms and References  . . . . . . . . . . . . . . . . . . . .   4
     2.1.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  References  . . . . . . . . . . . . . . . . . . . . . . .  10
     2.4.  Subset of a 6LoWPAN Glossary  . . . . . . . . . . . . . .  11
   3.  High Level Architecture . . . . . . . . . . . . . . . . . . .  12
     3.1.  6TiSCH Stack  . . . . . . . . . . . . . . . . . . . . . .  12
     3.2.  TSCH: A Deterministic MAC Layer . . . . . . . . . . . . .  14
     3.3.  Scheduling TSCH . . . . . . . . . . . . . . . . . . . . .  14
     3.4.  Routing and Forwarding Over TSCH  . . . . . . . . . . . .  16
     3.5.  A Non-Broadcast Multi-Access Radio Mesh Network . . . . .  17
     3.6.  A Multi-Link Subnet Model . . . . . . . . . . . . . . . .  19
   4.  Architecture Components . . . . . . . . . . . . . . . . . . .  20
     4.1.  6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . .  20
       4.1.1.  RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . .  21
       4.1.2.  RPL Root And 6LBR . . . . . . . . . . . . . . . . . .  21
     4.2.  Network Access and Addressing . . . . . . . . . . . . . .  22
       4.2.1.  Join Process  . . . . . . . . . . . . . . . . . . . .  22
       4.2.2.  Registration  . . . . . . . . . . . . . . . . . . . .  24
     4.3.  TSCH and 6top . . . . . . . . . . . . . . . . . . . . . .  26


     *   Works?



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

     *   will do, but that will take time and I do not want to hold my answer : )

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

     *   I can do that too, and place text in section 2 or 3. There is a difficult tension between the desire to shrink those sections that you expressed earlier and the request you’re making here.

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

     *   Problem there. We were asked to merge the 6TiSCH terminology document https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10  into the architecture to save RFC numbers and IESG cycles. We already used “define on first use” but the terminology was also useful when coming back to the doc or not reading it serially, as well as when reading another draft from the WG. I can move it to the appendix if that looks better, but I do not think we should eliminate or shrink dramatically what used to be a WG document just like that. We could try to convince Suresh (cc)  to resplit but there is little hope.
·        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).

     *   Will do; I’ll come back to you when I have progressed on all the above and probably published a rev so you can diff through easily. Note that again, this goes against a desire for increased conciseness. My understanding of what you describe looks a lot like a full book on 6TiSCH. I have no time to write that, I would if I did, and the reader is probably not expecting that from an IETF specification
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.

     *   It’s a nits thingy since we are going for std track. I’ll let the IESG sort that out with the DetNet architecture and will mimic when they are done.

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

  *

     *   This really depends on the “Schedule Management Mechanism”. The optimal is when a central controller owns hard cells and assigns them, in that case the node is a slave and does not consume energy for scanning. Else the use of chunks reduces the space where a node needs to scan for activity.
     *   I suggest adding the marked text below (note that section 4.4 is now 4.5 after moving pieces of section 3 in section 4:
4.3.5.  SlotFrames and CDU matrix

   6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC
   layer that is also capable of scheduled (deterministic)
   transmissions.  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 practically feasible, be free of contending
   energy.

   One simple way to obtain such a window is to format time and
   frequencies in cells of transmission of equal duration.  This is the
   method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long
   Term Evolution (LTE) of cellular networks.

   In order to describe that formatting of time and frequencies, the
   6TiSCH architecture defines a global concept that is called a Channel
   Distribution and Usage (CDU) matrix.  A CDU matrix is defined
   centrally as part of the network definition.  It is a matrix of cells
   with an height equal to the number of available channels (indexed by
   ChannelOffsets) and a width (in timeslots) that is the period of the
   network scheduling operation (indexed by slotOffsets) for that CDU
   matrix.  There are different models for scheduling the usage of the
   cells, which place the responsibility of avoiding collisions either
   on a central controller or on the devices themselves, at an extra
   cost in terms of energy to scan for free cells (more in Section 4.5).


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/


o    I meant a pair of bundles. Reworded below:


   Layer-2 vs. Layer-3 bundle:  Bundles are associated for either
               Layer-2 (switching) or Layer-3 (routing) forwarding
               operations.  A pair of Layer-3 bundles (one for each
               direction) maps to an IP Link with a neighbor, whereas a
               set of Layer-2 bundles (a number per neighbor, either
               from or to the neighbor) corresponds to the relation of
               one or more incoming bundle(s) from the previous-hop
               neighbor(s) with one or more outgoing bundle(s) to the
               next-hop neighbor(s) along a Track.

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…


o   It is really a cell in the CDU matrix identified by channeloffset and slotoffset. What about:
   cell:       A unit of transmission resource in the CDU matrix, a cell
               is identified by a slotOffset and a channelOffset.  A
               cell can be scheduled or unscheduled.


channelOffset:

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


o   It is really a cell in the CDU matrix identified by channeloffset and slotoffset. What about:

   channelOffset:  Identifies a row in the TSCH schedule.  The number of
               channelOffset values is bounded by the number of
               available frequencies.  The channelOffset translates into
               a frequency with a function that depends o the absolute
               time when the communication takes place, resulting in a
               channel hopping operation.




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

o   done



Track:
Expand DODAG-> Destination Oriented Directed Acyclic Graph

o   proposal:




   Track:      A Track is a Directed Acyclic Graph (DAG) that is used as
               a complex multi-hop path to the destination(s) of the
               path.  In the case of unicast traffic, the Track is a
               Destination Oriented DAG (DODAG) where the root of the
               DODAG is the destination of the unicast traffic.  A Track
               enables replication, elimination and reordering functions …





Section 3.6, 1st para:

       This architecture requires work to standardize the the
s/the the/the/

o   done



Section 4.1


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

o   done





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.


o   done





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.

o   done



Same para below:

       It results that a frame
s/It results that a frame/It results in a frame/

o   done, twice







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.




o    In DetNet Packet Replication and Elimination Function (PREF), multiple copies of a packet can be received and duplicates can be recognized and eliminated because they have the same sequence number.

o   What about
4.8.2.  Replication, Retries and Elimination

   6TiSCH supports the PREOF operations of elimination and reordering of
   packets along a complex Track, but has no requirement about whether a
   sequence number would be tagged in the packet for that purpose.  With
   6TiSCH, the schedule can tell when multiple receive timeslots
   correspond to copies of a same packet, in which case the receiver may
   avoid listening to the extra copies once it had received one instance
   of the packet.





   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 an ‘OR’/with an ‘OR’/
s/with an ‘AND’/with an ‘AND’/

o   done, for both



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


o   done