Re: [6tisch] Timing policy on 6P transactions

Hi Thomas,

> On 09 Dec 2016, at 15:28, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
> 
> Glenn,
> 
> Do you plan on participating at the call in 34min? I will add an action point to discuss about it.

Unfortunately, today I’m not able to participate in the call. 

> 
> My take is that 6P signaling traffic is nothing different from regluar traffic, and I don't believe we have any text anywhere that mandates a particular cell/slotframe to be used for it. Why not just let 6P traffic flow on the same cells at DATA, and let SF0 size the bundle between the neighbor nodes so it offers enough bandwidth for all traffic.

Ok, thanks. I was confused about this because of this section, https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.2 <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.2>, where it is mentioned that 6P could be used alongside the minimal configuration slotframe. I thought that the second slotframe (“slotframe 1”) had the specific goal to allow the exchange of 6P messages. It seems that I interpreted that section wrongly.

> 
> About the simyulation, Malisa is spearheading the project. I'll let him update you.

In the meanwhile, he already updated me: the shared slots should work. 

> 
> Thomas

Thanks,
Glenn

-- 
Glenn Daneels
IDLab research group
Dept. Mathematics and Computer Science
University of Antwerp - imec
Campus Middelheim, Building G, Office M.G.212
Email: glenn.daneels@uantwerpen.be

> 
> On Wed, Nov 30, 2016 at 7:03 PM, Glenn Daneels <glenn.daneels@uantwerpen.be <mailto:glenn.daneels@uantwerpen.be>> wrote:
> Dear all,
> 
> I am wondering if there is any policy on when 6P reservations request and responses (the “6P transaction”) should be sent (when e.g. doing neighbor-to-neighbor scheduling). In the 6TiSCH minimal configuration there is not really a need for this because of the static schedule (the one active cell). But when using a dynamic scheduler as SF0, the 6P requests and responses should also be sent. In the "6TiSCH Operation Sublayer (6top)”, it is suggested that 6P can be used with the minimal configuration (https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-04#section-2.2 <https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-04#section-2.2>); it is recommended that two types of slotframes are used: one (SFR0) for the Minimal 6TiSCH configuration and one (SFR1) for 6P to allocate cells from. Should SFR1 then be used for the 6P ADD and RESPONSE messages or is this slotframe only meant to allocate data transmissions cells from (and should the actual ADD and RESPONSE messages be sent somewhere else) or both? What is the current recommended policy for this (if there is any)? Is it for example also possible that 6P messages are sent in between normal data transmissions and thus not in a separate, dedicated slotframe?
> 
> I am also wondering if there is a similar policy on which type of cell should preferably be used for 6P ADD and RESPONSE messages (or other 6P commands in general): should one choose for Transmit or Shared cells? For me, the second option looks the more intuitive one as you could have some kind of minor management slotframe in which the motes contend to do 6P transactions (but of course, having such a “shared” management frame could be a bit much in the context of TSCH).
> 
> I do not any other information on this topic in the different drafts or mailing list.
> 
> As a third and last question, related to those shared cells, I noticed that there is some work done in the 6TiSCH simulator on shared cells by Xavier Vilajosana and Mališa Vučinić. Is the usage of a shared cell fully working or is this work in progress as I see that the commits are very recent?
> 
> Kind regards,
> Glenn
> 
> -- 
> Glenn Daneels
> IDLab research group
> Dept. Mathematics and Computer Science
> University of Antwerp - imec
> Campus Middelheim, Building G, Office M.G.212
> Email: glenn.daneels@uantwerpen.be <mailto:glenn.daneels@uantwerpen.be>
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org <mailto:6tisch@ietf.org>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
> 
> 
> -- 
> _______________________________________
> 
> Thomas Watteyne, PhD
> Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Linear Tech
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
> 
> www.thomaswatteyne.com <http://www.thomaswatteyne.com/>
> _______________________________________
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch