Subject: Re: [Detnet] FW: New Version Notification for draft-thubert-6tisch-4detnet-00.txt

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 15 Jul 2015 09:29:53 +0000

Hi Pascal,

Thanks for having put this together. 
I have read the draft v01 since long time, and only now finally able to provide you some feedback.

The draft explains well how the 6TiSCH architecture works, when a centralized approach is used, and what is needed from DetNet to build schedules in a centralized fashion, for setting up tracks, tagging packets, etc.

There is only one concept that IMHO is not that clear, and it creates a bit of confusion.
You use Track for explaining two different concepts (based on my understanding).
At the beginning (pag. 5) you describe a track as:

<< is a complex form of a  uni-directional Circuit ([I-D.ietf-6tisch-terminology]).  As opposed   to a simple circuit that is a sequence of nodes and links, a Track is shaped as a directed acyclic graph towards a destination to support  multi-path forwarding and route around failures.  A Track may also
   branch off and rejoin, for the purpose of the so-called Packet  Replication and Elimination (PRE), over non congruent branches. >>

and still according to this, at pag. 9 you refer to a track as a possible <<6TiSCH topology>>.

This in IMHO in conflict with the definition of track to which we are (or at least I am) used, according to [I-D.ietf-6tisch-terminology]), and which you also use inside this draft:

<< A Track is a unidirectional path between a source and a destination.  In a Track cell, the normal operation of IEEE802.15.4 Automatic Repeat-reQuest (ARQ) usually happens, though the acknowledgment may  be omitted in some cases, for instance if there is no scheduled cell
   for a retry..... A Track is thus formed end-to-end as a succession of paired bundles,    a receive bundle from the previous hop and a transmit bundle to the next hop along the Track, and a cell in such a bundle belongs to at  most one Track.>>  

Is there maybe the need to differentiate the two concepts with two different terms, or is it me missing something?

Another thing, that I would like to discuss is about chunk.
At pag. 8, you write:

<< The appropriation of a chunk can be requested explicitly by the PCE  to any node.  After a successful appropriation, the PCE owns the  cells in that chunk, and may use them as hard cells to set up Tracks. >>

In my understanding, it should be other nodes to request the appropriation of a chunk to the PCE.
The PCE should own all of them, being the one building the CDU, and the chunks. Then different (parent) nodes in the network may ask for chunks, and they will assign the cells within the chunk to their children. Is it correct?

Finally, something that 6TiSCH may need from DetNet is also the management/coordination of several PCEs.
It is luckily that we will have more than one PCE, and we will need some mechanisms to coordinate the inter-controllers synchronization, especially if a track is crossing several domains, under the control of different PCEs.
Of course we first need to solve the simplest scenario, with one PCE, but we should take into account also this.

Thank you,
Maria Rita

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, June 4, 2015 6:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] FW: New Version Notification for draft-thubert-6tisch-4detnet-00.txt

Dear all:

I prepared this based on Archie-1 to support 6TiSCH needs at DetNet.
It is only a 00 and I'll enrich it soon. Still I thought relevant to share the early work.

What do you all think?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: jeudi 4 juin 2015 17:58
To: Pascal Thubert (pthubert); Pascal Thubert (pthubert)
Subject: New Version Notification for draft-thubert-6tisch-4detnet-00.txt

A new version of I-D, draft-thubert-6tisch-4detnet-00.txt
has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Name:		draft-thubert-6tisch-4detnet
Revision:	00
Title:		6TiSCH requirements for DetNet
Document date:	2015-06-04
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-thubert-6tisch-4detnet-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thubert-6tisch-4detnet/
Htmlized:       https://tools.ietf.org/html/draft-thubert-6tisch-4detnet-00

Abstract:
   This document builds on the 6TiSCH architecture that defines, among
   others, mechanisms to establish and maintain deterministic routing
   and scheduling in a centralized fashion.  The document details
   dependencies on DetNet and PCE controller to express topologies and
   capabilities, as well as abstract state that the controller must be
   able to program into the network devices to enable deterministic
   forwarding operations.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 18 Jul 2015 10:59:04 +0000

Hello Maria Rita
 
> The draft explains well how the 6TiSCH architecture works, when a
> centralized approach is used, and what is needed from DetNet to build
> schedules in a centralized fashion, for setting up tracks, tagging packets, etc.
> 
> << is a complex form of a  uni-directional Circuit ([I-D.ietf-6tisch-
> terminology]).  As opposed   to a simple circuit that is a sequence of nodes
> and links, a Track is shaped as a directed acyclic graph towards a destination
> to support  multi-path forwarding and route around failures.  A Track may
> also
>    branch off and rejoin, for the purpose of the so-called Packet  Replication
> and Elimination (PRE), over non congruent branches. >>

Yes,

We have not really discussed PRP vs. ARQ, we should dig more and the draft is an occasion to do that. PRP allows multiple copies to circulate over different paths and eliminates the duplications at some places in the network (or the end point). It is really a different form of reliability with additional diversity (spatial diversity).

What we defined is that a PCE configures is an incoming bundle and an outgoing bundle. Packets received on an incoming bundle are switched on an outgoing bundle. 

There may be multiple ways for using that, and that's a PCE game to decide how it works. For instance we allow a packet to be received by more than one node since the destination MAC is 0xFFFF. Two or more nodes may be listening on a same time slot which is common to their incoming bundles (or 2 different time slots in the same outgoing bundle), in which case we achieve a frame replication. Some incoming slots may be coming from different peers in which case we are doing an elimination.

Now the questions are:

Do we define a pair of bundles per packet in which case we do not need a sequence counter?
Do we want ARQ and then how does it work?

> and still according to this, at pag. 9 you refer to a track as a possible

Well a track defines a topology, right? It is computed by the PCE as opposed to RPL but that is still a graph, isn't it?

> 
> This in IMHO in conflict with the definition of track to which we are (or at
> least I am) used, according to [I-D.ietf-6tisch-terminology]), and which you
> also use inside this draft:
> 
> << A Track is a unidirectional path between a source and a destination.  In a
> Track cell, the normal operation of IEEE802.15.4 Automatic Repeat-reQuest
> (ARQ) usually happens, though the acknowledgment may  be omitted in
> some cases, for instance if there is no scheduled cell
>    for a retry..... A Track is thus formed end-to-end as a succession of paired
> bundles,    a receive bundle from the previous hop and a transmit bundle to
> the next hop along the Track, and a cell in such a bundle belongs to at  most
> one Track.>>
> 
> Is there maybe the need to differentiate the two concepts with two
> different terms, or is it me missing something?

I think we want to extend the definition f track so that it can be more complex than a suite of node. What do others think?

> << The appropriation of a chunk can be requested explicitly by the PCE  to
> any node.  After a successful appropriation, the PCE owns the  cells in that
> chunk, and may use them as hard cells to set up Tracks. >>
> 
> The PCE should own all of them, being the one building the CDU, and the
> chunks. Then different (parent) nodes in the network may ask for chunks,
> and they will assign the cells within the chunk to their children. Is it correct?
> 
> It is luckily that we will have more than one PCE, and we will need some
> mechanisms to coordinate the inter-controllers synchronization, especially
> if a track is crossing several domains, under the control of different PCEs.

Well, the bundle manager is logically a different entity, so logically the PCE appropriates some bundles as well. 
The difference is that the chunks that the PCE owns are composed of hard cells.

Do we agree?

> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>