Subject: [6tisch] TG4e data frame and subsequent ACK

From: Rene Struik <[email-masked]>
Date: Tue, 04 Feb 2014 18:19:00 -0500

Hi Jonathan:

Can you remind me whether TSCH with 802.15.4e always follows the 
(receive frame from A; send ACK to A) format for recipient device B 
during a time slot? Or, is it also possible to use the (receive frame 
from A; send frame to A) format for recipient B? (of course, 
corresponding operation for A would then be (send frame; receive frame) 
within a timeslot (i.e., without using explicit ACK here). The latter 
could potentially be useful in reducing the time latency of security 
protocols that consist of a number of (send; receive), resp. (receive; 
send) flows, in contexts where device pairs {A,B} do not have shared 
keying material yet.

With TG4e, one has 4us/bit = 32 us/octet = 4.096 ms/128B, thus allowing 
send frame/receive frame to be squeezed into a 10ms timeslot, while 
still allowing for some Tx/Rx turn-around time (aTurnAroundTime, from 
recollection).

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 4 Feb 2014 15:36:36 -0800

The timeslot is defined as receive packet from A, send ack to A.  There's nothing preventing you from sending an unacknowledged frame, but the TSCH MAC would not understand that it could use the remainder of the slot for something other than an ack. 

One way to do this would be to use an older data frame version for this packet to get a mix of unslotted 15.4 behavior (where what you describe is possible) and TSCH slotted behavior. The spec sort of says you're TSCH or not, but this combo mode doesn't seem unreasonable.  The main problem is that you lose the ack confirmation - the MAC really shouldn't rely on the data frame coming back to know that it's frame was received correctly based on the frame contents (layer crossing). 
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. 

On Feb 4, 2014, at 3:19 PM, Rene Struik wrote:

> Hi Jonathan:
> 
> Can you remind me whether TSCH with 802.15.4e always follows the (receive frame from A; send ACK to A) format for recipient device B during a time slot? Or, is it also possible to use the (receive frame from A; send frame to A) format for recipient B? (of course, corresponding operation for A would then be (send frame; receive frame) within a timeslot (i.e., without using explicit ACK here). The latter could potentially be useful in reducing the time latency of security protocols that consist of a number of (send; receive), resp. (receive; send) flows, in contexts where device pairs {A,B} do not have shared keying material yet.
> 
> With TG4e, one has 4us/bit = 32 us/octet = 4.096 ms/128B, thus allowing send frame/receive frame to be squeezed into a 10ms timeslot, while still allowing for some Tx/Rx turn-around time (aTurnAroundTime, from recollection).
> 
> Best regards, Rene
> 
> --

---

From: Rene Struik <[email-masked]>
Date: Tue, 04 Feb 2014 18:45:10 -0500

Hi Jonathan:

Thanks for your note. I was just looking for communication latency 
reducing mechanisms, where "bending the rules" may have benefits. 
Whether these benefits are worth it, given hidden cost, is another 
question altogether. However, we should not discard design options too 
soon here and try and be creative, even if just to sketch how different 
behaviors contribute to time latency.

The use case I considered would be in the context of a joining device, 
where one does not have shared keying material yet and where receiving 
flow #{n+1} back after sending flow #{n} implies that the previous flow 
was received properly (in terms of passing elementary level 1,2 incoming 
filtering), not necessarily in terms of internal computation on frame 
content (which could be computationally intensive).

Most of the 6TiSCH security discussion has been almost independent of 
actual underlying MAC behavior far, so it is good to bring this closer 
to stack behavioral considerations including TSCH/4e aspects, rather 
than completely independent of this.

Best regards, Rene

On 2/4/2014 6:36 PM, Jonathan Simon wrote:
> The timeslot is defined as receive packet from A, send ack to A. 
>  There's nothing preventing you from sending an unacknowledged frame, 
> but the TSCH MAC would not understand that it could use the remainder 
> of the slot for something other than an ack.
>
> One way to do this would be to use an older data frame version for 
> this packet to get a mix of unslotted 15.4 behavior (where what you 
> describe is possible) and TSCH slotted behavior. The spec sort of says 
> you're TSCH or not, but this combo mode doesn't seem unreasonable. 
>  The main problem is that you lose the ack confirmation - the MAC 
> really shouldn't rely on the data frame coming back to know that it's 
> frame was received correctly based on the frame contents (layer 
> crossing).
> -- 
> Jonathan Simon, Ph. D
> [email-masked] <mailto:[email-masked]>
>
>  This e-mail transmission, and any documents, files or previous 
> e-mail messages attached to it may contain confidential information 
> that is legally privileged. If you are not the intended recipient, or 
> a person responsible for delivering it to the intended recipient, you 
> are hereby notified that any disclosure, copying, distribution or use 
> of any of the information contained in or attached to this 
> transmission is STRICTLY PROHIBITED. If you have received 
> this transmission in error, please immediately notify me by reply 
> e-mail, or by telephone at (510) 400-2936, and destroy the 
> original transmission and its attachments without reading or saving in 
> any manner. Thank you.
>
>> corresponding operation for A would then be (send frame; receive 
>> frame) within a timeslot (i.e., without using explicit ACK here). The 
>> latter could potentially be useful in reducing the time latency of 
>> security protocols that consist of a number of (send; receive), resp. 
>> (receive; send) flows, in contexts where device pairs {A,B} do not 
>> have shared keying material yet.
>>
>> With TG4e, one has 4us/bit = 32 us/octet = 4.096 ms/128B, thus 
>> allowing send frame/receive frame to be squeezed into a 10ms 
>> timeslot, while still allowing for some Tx/Rx turn-around time 
>> (aTurnAroundTime, from recollection).
>>
>> Best regards, Rene
>>
>> -- 
>> email: [email-masked] <mailto:[email-masked]> | Skype: 
>> rstruik