Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Hi Michel,

It has been a long time since we worked together.

With respect to your question, there are really two issues here:

1)
Q: Should IEs be used for purposes above the MAC subayer of the 
Data-link layer?

A: There's been a lot of discussion of conveying TSCH and 
higher-sublayer functionality in IEs. From a layering perspective, there 
is no problem with that provided that the information is from or for the 
same layer, which I interpret as the entire Data-link layer.

It's a different issue if one considers carrying Network-layer or 
Transport-layer or Application-layer information; doing that introduces 
inter-layer coupling that reduces the compartmentalization and utility 
of the mix-and-match layering concept.

In summary, using IEs to convey intra-layer information is acceptable; 
using IEs to convey inter-layer information is not, as it means that the 
higher layer implementation is dependent on being mated to a specific 
lower layer and can't be readily supported by other lower layers (e.g., 
Ethernet or WiFi).

2)
Q: Can an IE in an ACK frame be used to convey a response to the 
immediately-preceding same-slot Data frame, and if so what are the 
limits on the information that can be included in the ACK frame's IE?

A: It is possible for an IE in an ACK frame to convey a response to the 
immediately-preceding same-slot Data frame, provided that
i) the ACK frame that contains the IE does not exceed the airtime 
reserved for that ACK within the slot, and
ii) the IE can be generated from information available to the MAC before 
or during MAC-level processing of the same-slot Data frame that triggers 
the ACK.

What this means in the hypothetical three-component implementation, 
where the RF and MAC are combined but the higher layers are in a 
separate microcontroller that uses some form of inter-CPU communication, 
is that it is not permissible to receive information in the Data frame, 
hand it off to the second microcontroller, then demand that the second 
microcontroller respond in time for the MAC to generate the required 
same-slot ACK.

Don't make the mistake of analyzing this in terms of microseconds at a 
given data rate; the architectural solution needs to work if the 
date-rates are scaled up to 60 GHZ optical communications and 
multi-Mbit/s bandwidth.

I've been through these issue repeatedly, starting with the initial 
technical meeting of IEEE 802 in early 1980, even as what is now the OSI 
Basic Reference Model was being created by Charlie Bachman, a colleague 
of mine in Honeywell (for which he was later rapporteur). In the decades 
since, I've gone through this analysis repeatedly. It always comes out 
the same: an intimate timing-dependent coupling of layers forecloses too 
many future options and evolutionary paths.

Just my opinion, of course,
-Tom
=====
On 2015.07.02 10:15, Michel Veillette wrote:
> Hi Tom, long time no see
>
> I'm assume that your answer to my question "Is there something already 
> available if the drafts to accommodate this use case?" is no.
>
> You seem to imply that IEs within Enhanced acknowledgment can be used 
> only by the MAC layer, is it the case? The only relevant text I can 
> find in IEEE 802.15.4e on this subject is:
>
> 4.5.4.3 Frame acknowledgment
>
> The receiving device may insert additional content in an enhanced 
> acknowledgment encapsulated as IEs. If
> the originator does not understand the IE content of the 
> acknowledgment, it is ignored, but the transmission is considered 
> successful.
>
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veillette@trilliantinc.com
> www.trilliantinc.com
> -----Original Message-----
> From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Tom Phinney
> Sent: 2 juillet 2015 12:46
> To: 6tisch@ietf.org
> Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
>
> All,
>
> It's tempting to consider coupling the MAC ACK/NAK immediate-response 
> with higher-layer functions. Unfortunately, end-product architectural 
> considerations mandate that this NEVER even be considered.
>
> Many industrial wireless products will have a two-module or 
> three-module structure, where 1) the RF and MAC are integrated into a 
> single chip with some analog support components, such as an RF 
> transmit power amplifier and receiver front-end;
> 2) the other communication protocol layers are in a separate 
> microcontroller, such as an MSP430-class micro; and
> 3) the process-related sensor(s) and actuator(s), which are the inputs 
> and outputs that connect to the physical world, such as a valve 
> positioner.
>
> Such a product structure permits evolution of the RF subsection as 
> newer communications standards become widely accepted, of the other 
> comm protocol layers as changes occur in the underlying 
> microcontrollers (due largely to smartphone and IIoT), and of reuse of 
> those common designs throughout the product line, mating them with 
> different sensors and actuators, everything from the reasonable-size 
> positioner for a 3 m diameter valve to a very small lick-and-stick 
> corrosion sensor to go on pipes that might be 10 m above the ground.
>
> -Tom
>
> On 2015.07.02 08:25, Michel Veillette wrote:
>>
>> Hi Pascal
>>
>> I’m trying to address a different use case I thinks, when the  number 
>> of timeslots is limited. This use case is probably more relevant to 
>> large scale NAN networks (e.g. Zigbee NAN).
>>
>>
>> This use case is as follow.
>>
>>
>> Let say I have a RPL parent with 100 RPL children with a timeslot of 
>> 10 msec. If I want to assign a dedicated timeslot to each child, 100 
>> timeslots need to be assigned. This means that a timeslot for uplink 
>> traffic will available to a child only each couple of seconds. The 
>> propose approach allows the RPL parent to reserve soft cells to 
>> allocate bandwidth dynamically to some of these 100 children when 
>> needed.
>>
>>
>> Is this make some sense?
>>
>> Is there something already available if the drafts to accommodate 
>> this use case?
>>
>>
>> cid:image001.jpg@01C868D8.BF0BB7E0
>> 	
>>
>> Michel Veillette
>> System Architecture Director
>>
>> Trilliant Inc.
>> Tel: 450-375-0556 ext. 237
>> michel.veillette@trilliantinc.com
>>
>> www.trilliantinc.com
>>
>>
>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
>> Sent: 2 juillet 2015 10:40
>> To: Michel Veillette; Qin Wang; Nicola Accettura
>> Cc: 6tisch@ietf.org; diego.dujovne@mail.udp.cl
>> Subject: RE: [6tisch] draft-dujovne-6tisch-on-the-fly-05
>>
>>
>> Hello Michel:
>>
>>
>> We discussed an angle of this on the call of 22 Nov 2013 recording 
>> here :
>>
>>
>> https://bitbucket.org/6tisch/meetings/wiki/131122_webex at 8:13
>>
>> 
>> https://bitbucket.org/6tisch/meetings/src/master/131122_webex/slides_131122_webex.ppt
>>
>>
>>
>> In short, if the schedule is rather not busy, we can have more 
>> timeSlots per child than they really need.
>>
>>
>> In that case, the peer would only listen to the first timeSlot of a 
>> sequence of say 4. If there is no traffic there, the peer would not 
>> listen for the other 3. But if there is traffic, then the sender can 
>> indicate whether there’s more till done, in which case all the 
>> timeSlots could be used on that round.
>>
>>
>> This avoids negotiation to allocate / deallocate time slots.
>>
>>
>> Cheers,
>>
>>
>> Pascal
>>
>>
>> From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Michel 
>> Veillette
>> Sent: mercredi 1 juillet 2015 19:10
>> To: Qin Wang; Nicola Accettura
>> Cc: 6tisch@ietf.org; diego.dujovne@mail.udp.cl
>> Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
>>
>>
>> Hi Qin
>>
>>
>> Yes, the Frame Pending flag is defined as follow:
>>
>>
>> IEEE 802.15.4-2006 section 7.2.1.1.3
>>
>> “Frame Pending subfield is 1 bit in length and shall be set to one if 
>> the device sending the frame has more data for the recipient. This 
>> subfield shall be set to zero otherwise”
>>
>>
>> This feature can be especially useful for the upstream traffic in a 
>> RPL DODAG. In a scenario where a DAG parent have dozens of children, 
>> dedicated timeslot will be infrequent and share timeslots suffer from 
>> contention. If a subset of these children have ongoing traffic, the 
>> parent can use the Frame Pending flag information to schedule 
>> temporary soft cells and avoid contention or speedup transfer.
>>
>>
>>
>> cid:image001.jpg@01C868D8.BF0BB7E0
>> 	
>>
>> Michel Veillette
>> System Architecture Director
>>
>> Trilliant Inc.
>> Tel: 450-375-0556 ext. 237
>> michel.veillette@trilliantinc.com
>>
>> www.trilliantinc.com
>>
>>
>> From: Qin Wang [mailto:qinwang6top@yahoo.com]
>> Sent: 1 juillet 2015 11:28
>> To: Nicola Accettura; Michel Veillette
>> Cc: 6tisch@ietf.org; diego.dujovne@mail.udp.cl
>> Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
>>
>>
>> Hi Michel and Nicola,
>>
>>
>> I think Michel's idea is interesting. But, according to my 
>> understanding, the Frame Pending setting just means there is frame 
>> following, does not mean that the current bandwidth provided by TSCH 
>> schedule, including hard cells and soft cells, is not enough to 
>> convey those frames, and then needs more bandwidth (e.g. additional 
>> soft cells) . Right? Do I miss something?
>>
>>
>> Thanks
>>
>> Qin
>>
>>
>>
>> On Wednesday, July 1, 2015 4:03 AM, Nicola Accettura 
>> <nick.accettura@gmail.com> wrote:
>>
>>
>> Hi Michel,
>>
>> your proposal is very interesting.
>>
>> However, OTF does not allocate cells directly: it just computes the 
>> estimated number of cells to add or delete into the schedule, and 
>> then sends this information to 6top. 6top is then in charge of 
>> negotiating cells among neighbors, and meybe perform the scheme you 
>> are proposing.
>>
>> So, your proposal seems fitting more the 6top-to-6top communication.
>>
>> Am I missing something? What others think about?
>>
>> Sincerely
>>
>> Nicola
>>
>>
>> 2015-06-30 8:13 GMT-07:00 Michel Veillette 
>> <Michel.Veillette@trilliantinc.com>:
>>
>>     Hi Diego
>>
>>
>>     It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and 
>> I’m not completely done yet) and I wandering if the concept of on the 
>> fly, in a single exchange, temporary allocation of a soft cell have 
>> already been discussed. For example, a node can use the Frame Pending 
>> subfield (IEEE 802.15.4-2006 section 7.2.1.1.3) to indicate the 
>> presence of packets ready to be transmitted. Based on that knowledge, 
>> the target may add an IE in an enhanced acknowledgment to allocate a 
>> temporary soft cell (e.g. single cell). Each subsequent transmission 
>> may further re-allocate a temporary soft cell. It’s important to note 
>> that the default delay for a TSCH Acknowledgment is 1ms 
>> (macTsTxAckDelay) which seem sufficient for the processing of this 
>> new IE.
>>
>>
>>
>>
>>     This scheme is very reactive and may help dealing with 
>> non-predictable communication patterns.
>>
>>     What do you things?
>>
>>
>>     Michel Veillette
>>     System Architecture Director
>>
>>     Trilliant Inc.
>>     Tel: 450-375-0556 ext. 237
>>     michel.veillette@trilliantinc.com
>>
>>     www.trilliantinc.com
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch