Subject: Re: [6tisch] Reuse MAC ack vs 6top ack when using block option

From: Tom Phinney <[email-masked]>
Date: Fri, 09 May 2014 16:37:33 -0700

The alternatives below seem to be based on an incorrect inference
that the CPU that processes the received MAC message and generates
the immediate MAC-ACK reply is the same computer as the one that
processes the higher-layer aspects of the protocol.

In many implementations of devices, both of those which I think of
as "field devices" and those that are closer to the backbone, the RF
and MAC are handled by a smart RF chip while the remainder of the
device's tasks are handled by a larger but less reactive computer
such as an MSP430 or a low-power ARM. In such cases receipt of a
MAC-ACK implies only that the preceding message was received  by the
ACK'ing node without detected  PHY or MAC errors; it does not imply
that any inspection of the MAC payload has yet occurred. Thus, in
general, NO inference can be drawn from receipt of a
MAC-ACK except that delivery to the replying node occurred without
that node detecting a PHY or MAC error.

Of course, if the device receiving the ACK has sufficient knowledge
of the internal implementation of the ACK'ing device, then a more
extensive inference might be drawn. But without such detailed
knowledge, which would necessarily include at least the make, model
number and software and firmware revisions of the ACK'ing device, NO
inference of higher-layer acceptability can occur.

-Tom

=====

On 2014.05.09 15:48, Raghuram Sudhaakar
(rsudhaak) wrote:

All,

In the meeting this morning we discussed the issue of reusing
the MAC layer ack for the CoAP blocks (when using block option).
The discussion centered around the efficiency of using the MAC
layer ACK vs the separation/reliability of using an ack at the
6top layer.

The other pros/cons discussed were

1)MAC layer ack may not be available/lost in situations
wherein the device may drop packets due to congestion/other
errors.

2)There is a very short turnaround time between the reception
of a packet and the transmission of the ACK at the mac layer
(~192us). This may be very short time to process the CoAP
message and respond as necessary.

3) Usage of extended may be a possibility

4) An ideal tradeoff may be to use a 6top ACK for the entire
payload and use the MAC ack for the ARQ of individual blocks.

I request comments/opinions on this topic from the group that
will help us reach the best tradeoff/solution.

-raghuram

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 22 May 2014 16:12:12 -0700

Tom,

I understand and agree with your comments.

IEEE802.15.4e-2012, however, allows for any IEs to be present in the ACK,
which includes the wrapper IE also.

This means that the CoAP-ACK could be sent back in two fashions:
1. in a wrapper IE as part of the MAC-ACK
2. in a wrapper IE as part of data payload in a subsequent cell

Per Tom's comment, we cannot force all implementations to use only option
1. The last question is whether we actively prevent implementations from
doing so.

Ideas?

Thomas

On Fri, May 9, 2014 at 4:37 PM, Tom Phinney <[email-masked]> wrote:

>  The alternatives below seem to be based on an incorrect inference that
> the CPU that processes the received MAC message and generates the immediate
> MAC-ACK reply is the same computer as the one that processes the
> higher-layer aspects of the protocol.
>
> In many implementations of devices, both of those which I think of as
> "field devices" and those that are closer to the backbone, the RF and MAC
> are handled by a smart RF chip while the remainder of the device's tasks
> are handled by a larger but less reactive computer such as an MSP430 or a
> low-power ARM. In such cases receipt of a MAC-ACK implies only that the
> preceding message was received  by the ACK'ing node without detected  PHY
> or MAC errors; it does not imply that any inspection of the MAC payload has
> yet occurred. Thus, in general, *NO* inference can be drawn from receipt
> of a MAC-ACK except that delivery to the replying node occurred without
> Of course, if the device receiving the ACK has sufficient knowledge of the
> internal implementation of the ACK'ing device, then a more extensive
> inference might be drawn. But without such detailed knowledge, which would
> necessarily include at least the make, model number and software and
> firmware revisions of the ACK'ing device, *NO* inference of higher-layer
> acceptability can occur.
>
> -Tom
> =====
>
> On 2014.05.09 15:48, Raghuram Sudhaakar (rsudhaak) wrote:
>
> All,
> In the meeting this morning we discussed the issue of reusing the MAC
> layer ack for the CoAP blocks (when using block option). The discussion
> centered around the efficiency of using the MAC layer ACK vs the
> separation/reliability of using an ack at the 6top layer.
>
> 1)MAC layer ack may not be available/lost in situations wherein the device
> may drop packets due to congestion/other errors.
> 2)There is a very short turnaround time between the reception of a packet
> and the transmission of the ACK at the mac layer (~192us). This may be very
> short time to process the CoAP message and respond as necessary.
> 4) An ideal tradeoff may be to use a 6top ACK for the entire payload and
> use the MAC ack for the ARQ of individual blocks.
>
>  I request comments/opinions on this topic from the group that will help
> us reach the best tradeoff/solution.
>
>  -raghuram
>
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 23 May 2014 05:16:43 +0200

Hi Thomas,

I just want to add that for the case 1, the wrapperIE in the received data
packet should be processed immediately, i,e the "CoAP Payload" pushed up to
6top quickly. As you say, the ACK can contain a wrapper IE but this wrapper
IE should contain the result determined by 6top after processing the
received wrapper IE. This consideration is important because

1)the time between last byte received in a slot and the first byte of the
ack is short
2) usually 15.4e uses queues or asynchronous communication to talk to upper
layers

Here it seems that for the MAC layer to answer we need the response of
layer 2.5.

I assume that's why you consider avoiding that case. Am I right?
X

2014-05-23 1:12 GMT+02:00 Thomas Watteyne <[email-masked]>:

>> Of course, if the device receiving the ACK has sufficient knowledge of
>> the internal implementation of the ACK'ing device, then a more extensive
>> 1)MAC layer ack may not be available/lost in situations wherein the
>> device may drop packets due to congestion/other errors.

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 22 May 2014 21:19:29 -0700

Xavi,

Yes, that's what I mean.

As pointed out by Tom, the entity that creates the MAC-ACK is the MAC
layer, not an upper layer (e.g. 6top) capable of generating the CoAP-ACK.

I believe it would be a mistake to force the CoAP-ACK to be piggybacked in
the MAC-ACK. But, for the cases where it is possible, we shouldn't prevent
it either, since IEs can be part of the MAC-ACK.

So I'm in favor of leaving this up to the implementation of the receiver:
either generate the CoAP-ACK very fast and piggybacking it with the
MAC-ACK, or sending it later on as it's own data packet.

Thomas

On Thu, May 22, 2014 at 8:16 PM, Xavier Vilajosana <
[email-masked]> wrote:

> 2) usually 15.4e uses queues or asynchronous communication to talk to
> upper layers
>
>>> yet occurred. Thus, in general, *NO* inference can be drawn from
>>> receipt of a MAC-ACK except that delivery to the replying node occurred
>>> without that node detecting a PHY or MAC error.
>>>
>>> firmware revisions of the ACK'ing device, *NO* inference of
>>> higher-layer acceptability can occur.
>>>
>>> -Tom
>>> =====
>>>
>>> 2)There is a very short turnaround time between the reception of a
>>> packet and the transmission of the ACK at the mac layer (~192us). This may
>>> be very short time to process the CoAP message and respond as necessary.
>>>  I request comments/opinions on this topic from the group that will
>>> help us reach the best tradeoff/solution.
>>>
>>>  -raghuram
>>>
>>>

---

From: Tom Phinney <[email-masked]>
Date: Thu, 22 May 2014 22:12:23 -0700

I certainly have no problem with the approach that Thomas is
suggesting. Clearly it's more efficient to piggyback multiple layer
acks in a single transmission when that is feasible. The cost of
making that a option which the MAC-ACK'ing device can employ is only
that the sender must be able to handle the piggybacked CoAP-ACK in
IEs received from the MAC-ACK'ing device.

-Tom

===

On 2014.05.22 21:19, Thomas Watteyne
wrote:

Xavi,

Yes, that's what I mean.

As pointed out by Tom, the entity that creates the MAC-ACK
is the MAC layer, not an upper layer (e.g. 6top) capable of
generating the CoAP-ACK.

I believe it would be a mistake to force the CoAP-ACK to be
piggybacked in the MAC-ACK. But, for the cases where it is
possible, we shouldn't prevent it either, since IEs can be
part of the MAC-ACK.

So I'm in favor of leaving this up to the implementation of
the receiver: either generate the CoAP-ACK very fast and
piggybacking it with the MAC-ACK, or sending it later on as
it's own data packet.

Thomas

On Thu, May 22, 2014 at 8:16 PM,
Xavier Vilajosana <[email-masked]>
wrote:

Hi Thomas,

I just want to add that for the case 1, the
wrapperIE in the received data packet should be
processed immediately, i,e the "CoAP Payload" pushed
up to 6top quickly. As you say, the ACK can contain a
wrapper IE but this wrapper IE should contain the
result determined by 6top after processing the
received wrapper IE. This consideration is important
because

1)the time between last byte received in a slot and
the first byte of the ack is short

2) usually 15.4e uses queues or asynchronous
communication to talk to upper layers

Here it seems that for the MAC layer to answer we need
the response of layer 2.5.

I assume that's why you consider avoiding that
case. Am I right?

X

2014-05-23 1:12 GMT+02:00
Thomas Watteyne <[email-masked]>:

Tom,

IEEE802.15.4e-2012, however, allows for
any IEs to be present in the ACK, which
includes the wrapper IE also.

This means that the CoAP-ACK could be
sent back in two fashions:

2. in a wrapper IE as part of data
payload in a subsequent cell

Per Tom's comment, we cannot force all
implementations to use only option 1. The
last question is whether we actively prevent
implementations from doing so.

Ideas?

Thomas

On Fri, May 9,
2014 at 4:37 PM, Tom Phinney <[email-masked]>
wrote:

The alternatives below seem to be
based on an incorrect inference that
the CPU that processes the received
MAC message and generates the
immediate MAC-ACK reply is the same
computer as the one that processes
the higher-layer aspects of the
protocol.

In many implementations of devices,
both of those which I think of as
"field devices" and those that are
closer to the backbone, the RF and
MAC are handled by a smart RF chip
while the remainder of the device's
tasks are handled by a larger but
less reactive computer such as an
MSP430 or a low-power ARM. In such
cases receipt of a MAC-ACK implies
only that the preceding message was
received  by the ACK'ing node
without detected  PHY or MAC errors;
it does not imply that any
inspection of the MAC payload has
yet occurred. Thus, in general, NO
inference can be drawn from receipt
of a MAC-ACK except that delivery to
the replying node occurred without
that node detecting a PHY or MAC
error.

Of course, if the device receiving
the ACK has sufficient knowledge of
the internal implementation of the
ACK'ing device, then a more
extensive inference might be drawn.
But without such detailed knowledge,
which would necessarily include at
least the make, model number and
software and firmware revisions of
the ACK'ing device, NO
inference of higher-layer
acceptability can occur.

-Tom

=====

On 2014.05.09
15:48, Raghuram
Sudhaakar (rsudhaak) wrote:

All,

In the meeting this
morning we discussed the
issue of reusing the MAC
layer ack for the CoAP
blocks (when using block
option). The discussion
centered around the
efficiency of using the MAC
layer ACK vs the
separation/reliability of
using an ack at the 6top
layer.

The other pros/cons
discussed were

1)MAC layer ack may not
be available/lost in
situations wherein the
device may drop packets due
to congestion/other errors.

2)There is a very short
turnaround time between the
reception of a packet and
the transmission of the ACK
at the mac layer (~192us).
This may be very short time
to process the CoAP message
and respond as necessary.

3) Usage of extended may
be a possibility

4) An ideal tradeoff may
be to use a 6top ACK for the
entire payload and use the
MAC ack for the ARQ of
individual blocks.

I request
comments/opinions on this
topic from the group that
will help us reach the best
tradeoff/solution.

-raghuram

6tisch mailing list

[email-masked]

6tisch mailing list

[email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 23 May 2014 07:30:08 +0200

completely agree (+1)

X

2014-05-23 7:12 GMT+02:00 Tom Phinney <[email-masked]>:

>  I certainly have no problem with the approach that Thomas is suggesting.
> Clearly it's more efficient to piggyback multiple layer acks in a single
> transmission when that is feasible. The cost of making that a option which
> the MAC-ACK'ing device can employ is only that the sender must be able to
> handle the piggybacked CoAP-ACK in IEs received from the MAC-ACK'ing device.
>
> -Tom
> ===
>
> On 2014.05.22 21:19, Thomas Watteyne wrote:
>
> Xavi,
>
>  Yes, that's what I mean.
>
>  I believe it would be a mistake to force the CoAP-ACK to be piggybacked
> in the MAC-ACK. But, for the cases where it is possible, we shouldn't
> prevent it either, since IEs can be part of the MAC-ACK.
>
>  So I'm in favor of leaving this up to the implementation of the
> receiver: either generate the CoAP-ACK very fast and piggybacking it with
> the MAC-ACK, or sending it later on as it's own data packet.
>
>  Thomas
>
>
>>  I just want to add that for the case 1, the wrapperIE in the received
>> data packet should be processed immediately, i,e the "CoAP Payload" pushed
>> up to 6top quickly. As you say, the ACK can contain a wrapper IE but this
>> wrapper IE should contain the result determined by 6top after processing
>> the received wrapper IE. This consideration is important because
>>
>>  1)the time between last byte received in a slot and the first byte of
>> the ack is short
>>>  IEEE802.15.4e-2012, however, allows for any IEs to be present in the
>>> ACK, which includes the wrapper IE also.
>>>
>>>  Per Tom's comment, we cannot force all implementations to use only
>>> option 1. The last question is whether we actively prevent implementations
>>> from doing so.
>>>
>>>  Ideas?
>>>
>>>  Thomas
>>>
>>>
>>>> On 2014.05.09 15 <2014.05.09%2015>:48, Raghuram Sudhaakar (rsudhaak)
>>>> wrote:
>>>>
>>>>  All,
>>>> 4) An ideal tradeoff may be to use a 6top ACK for the entire payload
>>>> and use the MAC ack for the ARQ of individual blocks.
>>>>

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 May 2014 22:44:50 -0700 (PDT)

It implies that
(1) CoAP-Ack, instead of MAC Ack, should be used as acknowledge.
(2) CoAP-ACK will be wrapped in WrapperIE
(3) The WrapperIE can be carried in the Data frame or Ack frame of IEEE802.15.4

Right?

Thanks
Qin 

On Friday, May 23, 2014 1:35 PM, Xavier Vilajosana <[email-masked]> wrote:

completely agree (+1)

X

I certainly have no problem with the approach that Thomas is suggesting. Clearly it's more efficient to piggyback multiple layer acks in a single transmission when that is feasible. The cost of making that a option which the MAC-ACK'ing device can employ is only that the sender must be able to handle the piggybacked CoAP-ACK in IEs received from the MAC-ACK'ing device.
>>As pointed out by Tom, the entity that creates the MAC-ACK is the MAC layer, not an upper layer (e.g. 6top) capable of generating the CoAP-ACK.
>>
>>
>>I believe it would be a mistake to force the CoAP-ACK to be piggybacked in the MAC-ACK. But, for the cases where it is possible, we shouldn't prevent it either, since IEs can be part of the MAC-ACK.
>>
>>
>>So I'm in favor of leaving this up to the implementation of the receiver: either generate the CoAP-ACK very fast and piggybacking it with the MAC-ACK, or sending it later on as it's own data packet.
>>
>>
>>Thomas
>>
>>
>>
>>On Thu, May 22, 2014 at 8:16 PM, Xavier Vilajosana <[email-masked]> wrote:
>>
>>Hi Thomas,  
>>>
>>>
>>>I just want to add that for the case 1, the wrapperIE in the received data packet should be processed immediately, i,e the "CoAP Payload" pushed up to 6top quickly. As you say, the ACK can contain a wrapper IE but this wrapper IE should contain the result determined by 6top after processing the received wrapper IE. This consideration is important because 
>>>
>>>
>>>1)the time between last byte received in a slot and the first byte of the ack is short
>>>2) usually 15.4e uses queues or asynchronous communication to talk to upper layers
>>>
>>>
>>>Here it seems that for the MAC layer to answer we need the response of layer 2.5. 
>>>
>>>
>>>>
>>>>
>>>>IEEE802.15.4e-2012, however, allows for any IEs to be present in the ACK, which includes the wrapper IE also.
>>>>
>>>>
>>>>Per Tom's comment, we cannot force all implementations to use only option 1. The last question is whether we actively prevent implementations from doing so.
>>>>
>>>>
>>>>Ideas?
>>>>
>>>>
>>>>Thomas
>>>>
>>>>
>>>>
>>>>
>>>>The alternatives below seem to be based on an incorrect inference that the CPU that processes the received MAC message and generates the immediate MAC-ACK reply is the same computer as the one that processes the higher-layer aspects of the protocol. 
>>>>>
                                    yet occurred. Thus, in general, NO inference can be drawn from receipt of a MAC-ACK except that delivery to the replying node occurred without that node detecting a PHY or MAC error.
                                    the ACK'ing device, NO inference of higher-layer acceptability can occur.
>>>>>>In the meeting this morning we discussed the issue of reusing the MAC layer ack for the CoAP blocks (when using block option). The discussion centered around the efficiency of using the MAC layer ACK vs the separation/reliability of using an ack at the 6top layer.
>>>>>>
>>>>>>
>>>>>>1)MAC layer ack may not be available/lost in situations wherein the device may drop packets due to congestion/other errors.
>>>>>>2)There is a very short turnaround time between the reception of a packet and the transmission of the ACK at the mac layer (~192us). This may be very short time to process the CoAP message and respond as necessary.
>>>>>>4) An ideal tradeoff may be to use a 6top ACK for the entire payload and use the MAC ack for the ARQ of individual blocks.
>>>>>>
>>>>>>
>>>>>>I request comments/opinions on this topic from the group that will help us reach the best tradeoff/solution.
>>>>>>
>>>>>>
>>>>>>-raghuram
>>>>>>
>>>>>>
6tisch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/6tisch

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 23 May 2014 05:04:16 -0700

Yes, that's IMO what we could do.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 May 2014 13:32:46 +0000

Dear all:

Wouldn't you think that when the MAC reception is OK, then there is a huge chance that the operation at layer 2.5 fails.
Seems that this should be really an exception, if all there is to do is tar together the blocks.
And if it's an exception we could make the L2.5 ack of the block implicit and we'd have an explicit confirmable exception message when the block operation fails at 2.5.
If we take that path then we'd probably only do a global L2.5 ack at the end of the last block.

Would that make sense ?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: vendredi 23 mai 2014 07:45
To: Xavier Vilajosana; Tom Phinney
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tisch] Reuse MAC ack vs 6top ack when using block option

It implies that

Right?

Thanks
Qin
On Friday, May 23, 2014 1:35 PM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:

completely agree (+1)

X

2014-05-23 7:12 GMT+02:00 Tom Phinney <[email-masked]<mailto:[email-masked]>>:
I certainly have no problem with the approach that Thomas is suggesting. Clearly it's more efficient to piggyback multiple layer acks in a single transmission when that is feasible. The cost of making that a option which the MAC-ACK'ing device can employ is only that the sender must be able to handle the piggybacked CoAP-ACK in IEs received from the MAC-ACK'ing device.

-Tom
===

Yes, that's what I mean.

Thomas

On Thu, May 22, 2014 at 8:16 PM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas,

2014-05-23 1:12 GMT+02:00 Thomas Watteyne <[email-masked]<mailto:[email-masked]>>:

Tom,

Ideas?

Thomas

On Fri, May 9, 2014 at 4:37 PM, Tom Phinney <[email-masked]<mailto:[email-masked]>> wrote:
The alternatives below seem to be based on an incorrect inference that the CPU that processes the received MAC message and generates the immediate MAC-ACK reply is the same computer as the one that processes the higher-layer aspects of the protocol.

In many implementations of devices, both of those which I think of as "field devices" and those that are closer to the backbone, the RF and MAC are handled by a smart RF chip while the remainder of the device's tasks are handled by a larger but less reactive computer such as an MSP430 or a low-power ARM. In such cases receipt of a MAC-ACK implies only that the preceding message was received  by the ACK'ing node without detected  PHY or MAC errors; it does not imply that any inspection of the MAC payload has yet occurred. Thus, in general, NO inference can be drawn from receipt of a MAC-ACK except that delivery to the replying node occurred without that node detecting a PHY or MAC error.

Of course, if the device receiving the ACK has sufficient knowledge of the internal implementation of the ACK'ing device, then a more extensive inference might be drawn. But without such detailed knowledge, which would necessarily include at least the make, model number and software and firmware revisions of the ACK'ing device, NO inference of higher-layer acceptability can occur.

-Tom
=====

-raghuram

6tisch mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Fri, 23 May 2014 06:51:34 -0700 (PDT)

Hi Pascal,

I agree with Thomas. Regarding to your proposal, I think the problem is what should do if no MAC Ack return back.

What do you think?

Thanks
Qin

On Friday, May 23, 2014 9:32 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:

Dear all:
 
Wouldn’t you think that when the MAC reception is OK, then there is a huge chance that the operation at layer 2.5 fails. 
Seems that this should be really an exception, if all there is to do is tar together the blocks.
And if it’s an exception we could make the L2.5 ack of the block implicit and we’d have an explicit confirmable exception message when the block operation fails at 2.5.
If we take that path then we’d probably only do a global L2.5 ack at the end of the last block.
 
Would that make sense ?
 
Pascal
 
From:6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
 
It implies that
 
Right?
 
Thanks
Qin 
 
completely agree (+1)
 
X
 
>>>>In many implementations of devices, both of those which I think of as "field devices" and those that are closer to the backbone, the RF and MAC are handled by a smart RF chip while the remainder of the device's tasks are handled by a larger but less reactive
 computer such as an MSP430 or a low-power ARM. In such cases receipt of a MAC-ACK implies only that the preceding message was received  by the ACK'ing node without detected  PHY or MAC errors; it does not imply that any inspection of the MAC payload has yet
 occurred. Thus, in general, NO inference can be drawn from receipt of a MAC-ACK except that delivery to the replying node occurred without that node detecting a PHY or MAC error.
>>>>
>>>>Of course, if the device receiving the ACK has sufficient knowledge of the internal implementation of the ACK'ing device, then a more extensive inference might be drawn. But without such detailed knowledge, which would necessarily include at least the make,
 model number and software and firmware revisions of the ACK'ing device, NO inference of higher-layer acceptability can occur.

---

From: Pat Kinney <[email-masked]>
Date: Fri, 23 May 2014 09:56:04 -0500

I am sorry that I am so late getting into this thread, but I would like to relay some of the consensus from last week's IEEE 802.15.4 revision meetings concerning the enhanced ACK.  It was agreed that the enhanced ACK is really a response frame (note that we don't officially have a response frame).  An ACK is sent directly after receipt of the frame without using CCA, whereas the enhanced ACK is sent when directed to do so and must use CCA.  An ACK only contains sequence information, while the enhanced ACK can have significant information. 

An ACK is the result of three conditions: AR set to 1, frame is unicast with the destination address being the address of the receiver, and FCS is valid.  The enhanced ACK would have at least four conditions: AR set to 1, frame is unicast with the destination address being the address of the receiver, FCS is valid, and successful incoming frame security procedure.  

Therefore we agreed that the enhanced ACK is really a response from the receiving node to the transmitting node, indicating either ACK or NACK as well as other information.  Additionally, the enhanced ACK could be considered to be a higher layer response frame, since it can include data from the higher layers and can be sent when directed by the higher layer.

With this understanding in mind, could we consider using the enhanced ACK as a 6top ACK?

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On May 23, 2014, at 8:51 AM, Qin Wang <[email-masked]> wrote:

Hi Pascal,

What do you think?

Thanks
Qin

Dear all:

Would that make sense ?
 
Pascal

It implies that
 
Right?
 
Thanks
Qin 
 
completely agree (+1)
 
X

-Tom
===

Yes, that's what I mean.

 
 
Thomas

 

 
 
Tom,

 

Ideas?
 
Thomas

-Tom
=====

 
 
-raghuram

---

From: Rene Struik <[email-masked]>
Date: Fri, 23 May 2014 11:31:31 -0400

Dear colleagues:

This raises an interesting question: I understood 6tisch to be defined 
on top of the existing 802.15.4e-2012 specification. Or, am I wrong here 
and would this relate to a very preliminary draft spec (I don't think 
the first draft is available yet), which may ultimately be the outcome 
of the revision effort with IEEE 802.15.4 (with currently envisioned 
RevCom date of June 5, 2015).

Best regards, Rene

[excerpt from 6tisch charter]

The Working Group will focus on enabling IPv6 over the TSCH mode of the
IEEE802.15.4e standard. The extent of the problem space for the WG is
one or more LLNs, eventually federated through a common backbone link
via one or more LLN Border Routers (LBRs). The WG will rely on, and if
necessary extend, existing mechanisms for authenticating LBRs

On 5/23/2014 10:56 AM, Pat Kinney wrote:
> I am sorry that I am so late getting into this thread, but I would 
> like to relay some of the consensus from last week's IEEE 802.15.4 
> revision meetings concerning the enhanced ACK.  It was agreed that the 
> enhanced ACK is really a response frame (note that we don't officially 
> have a response frame).  An ACK is sent directly after receipt of the 
> frame without using CCA, whereas the enhanced ACK is sent when 
> directed to do so and must use CCA.  An ACK only contains sequence 
> information, while the enhanced ACK can have significant information.
>
> An ACK is the result of three conditions: AR set to 1, frame is 
> unicast with the destination address being the address of the 
> receiver, and FCS is valid.  The enhanced ACK would have at least four 
> conditions: AR set to 1, frame is unicast with the destination address 
> being the address of the receiver, FCS is valid, and successful 
> incoming frame security procedure.
>
> Therefore we agreed that the enhanced ACK is really a response from 
> the receiving node to the transmitting node, indicating either ACK or 
> NACK as well as other information.  Additionally, the enhanced ACK 
> could be considered to be a higher layer response frame, since it can 
> include data from the higher layers and can be sent when directed by 
> the higher layer.
>
> */Kinney Consulting LLC/*
> <mailto:[email-masked]>
>
>
> On May 23, 2014, at 8:51 AM, Qin Wang <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi Pascal,
>
> I agree with Thomas. Regarding to your proposal, I think the problem 
> is what should do if no MAC Ack return back.
>
> What do you think?
>
> Thanks
> Qin
>
>
>
> On Friday, May 23, 2014 9:32 PM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> Dear all:
> Wouldn't you think that when the MAC reception is OK, then there is a 
> huge chance that the operation at layer 2.5 fails.
> And if it's an exception we could make the L2.5 ack of the block 
> implicit and we'd have an explicit confirmable exception message when 
> the block operation fails at 2.5.
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Qin Wang
> *Sent:* vendredi 23 mai 2014 07:45
> *To:* Xavier Vilajosana; Tom Phinney
> *Cc:* Thomas Watteyne; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [6tisch] Reuse MAC ack vs 6top ack when using block option
> It implies that
> On Friday, May 23, 2014 1:35 PM, Xavier Vilajosana 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> completely agree (+1)
> X
>     suggesting. Clearly it's more efficient to piggyback multiple
>     layer acks in a single transmission when that is feasible. The
>     cost of making that a option which the MAC-ACK'ing device can
>     employ is only that the sender must be able to handle the
>     piggybacked CoAP-ACK in IEs received from the MAC-ACK'ing device.
>
>     -Tom
>     ===
>         As pointed out by Tom, the entity that creates the MAC-ACK is
>         the MAC layer, not an upper layer (e.g. 6top) capable of
>         generating the CoAP-ACK.
>         On Thu, May 22, 2014 at 8:16 PM, Xavier Vilajosana
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi Thomas,
>             I just want to add that for the case 1, the wrapperIE in
>             the received data packet should be processed immediately,
>             i,e the "CoAP Payload" pushed up to 6top quickly. As you
>             say, the ACK can contain a wrapper IE but this wrapper IE
>             should contain the result determined by 6top after
>             processing the received wrapper IE. This consideration is
>             important because
>             2014-05-23 1:12 GMT+02:00 Thomas Watteyne
>             <[email-masked]
>             <mailto:[email-masked]>>:
>
>                 Tom,
>                 IEEE802.15.4e-2012, however, allows for any IEs to be
>                 present in the ACK, which includes the wrapper IE also.
>                 Per Tom's comment, we cannot force all implementations
>                 to use only option 1. The last question is whether we
>                 actively prevent implementations from doing so.
>                 Ideas?
>                 Thomas
>                 On Fri, May 9, 2014 at 4:37 PM, Tom Phinney
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>                 The alternatives below seem to be based on an
>                 incorrect inference that the CPU that processes the
>                 received MAC message and generates the immediate
>                 MAC-ACK reply is the same computer as the one that
>                 In many implementations of devices, both of those
>                 which I think of as "field devices" and those that are
>                 closer to the backbone, the RF and MAC are handled by
>                 a smart RF chip while the remainder of the device's
>                 tasks are handled by a larger but less reactive
>                 computer such as an MSP430 or a low-power ARM. In such
>                 cases receipt of a MAC-ACK implies only that the
>                 preceding message was received  by the ACK'ing node
>                 without detected  PHY or MAC errors; it does not imply
>                 that any inspection of the MAC payload has yet
>                 occurred. Thus, in general, *_NO_* inference can be
>                 drawn from receipt of a MAC-ACK except that delivery
>                 to the replying node occurred without that node
>                 detecting a PHY or MAC error.
>
>                 Of course, if the device receiving the ACK has
>                 sufficient knowledge of the internal implementation of
>                 the ACK'ing device, then a more extensive inference
>                 might be drawn. But without such detailed knowledge,
>                 which would necessarily include at least the make,
>                 model number and software and firmware revisions of
>                 the ACK'ing device, *_NO_* inference of higher-layer
>                 acceptability can occur.
>
>                 -Tom
>                 =====
>                     In the meeting this morning we discussed the issue
>                     of reusing the MAC layer ack for the CoAP blocks
>                     (when using block option). The discussion centered
>                     around the efficiency of using the MAC layer ACK
>                     vs the separation/reliability of using an ack at
>                     the 6top layer.
>                     1)MAC layer ack may not be available/lost in
>                     situations wherein the device may drop packets due
>                     2)There is a very short turnaround time between
>                     the reception of a packet and the transmission of
>                     the ACK at the mac layer (~192us). This may be
>                     very short time to process the CoAP message and
>                     respond as necessary.
>                     4) An ideal tradeoff may be to use a 6top ACK for
>                     the entire payload and use the MAC ack for the ARQ
>                     of individual blocks.
>                     I request comments/opinions on this topic from the
>                     group that will help us reach the best
>                     tradeoff/solution.
>                     -raghuram
>
>
>                     [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

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

---

From: Kris Pister <[email-masked]>
Date: Fri, 23 May 2014 08:48:52 -0700

In addition, we need to keep in mind the timing in a slot.  At 15ms we 
have a fair amount of room,
but if we move to something more efficient like 10ms, then there will be 
an upper bound
on the size of the ACK, shy of a 127 byte max PDU.

ksjp

---

From: Qin Wang <[email-masked]>
Date: Fri, 23 May 2014 18:56:21 -0700 (PDT)

Hi Pat,

Do you mean a node can send back Enhanced Ack in a different slot? If yes, is there any time constraint on the interval between the time when a node receives a packet and the time when the node sends back corresponding Enhanced Ack? 

For example, a pair of nodes, nodeA and nodeB have two slots in a slotframe, slotoffset=10 (nodeA Tx) and slotoffset=80 (nodeB Tx). On slotoffset=10, nodeB receives a data frame with WrapperIE(CoAP-PUT) from nodeA, and on slotoffset=80, nodeB gets chance to sends back a packet with  WrapperIE (CoAP-ACK). 

My question is: Can a Enhanced Ack be used to carry the WapperIE(CoAP-ACK)? If yes, what is the advantage comparing with using MAC Data frame to carry the WapperIE(CoAP-ACK)?

Thanks
Qin

On Friday, May 23, 2014 10:56 PM, Pat Kinney <[email-masked]> wrote:

Pat

Pat Kinney
Kinney Consulting LLC

Hi Pascal,

What do you think?

Thanks
Qin

Dear all:

Would that make sense ?
 
Pascal

It implies that
 
Right?
 
Thanks
Qin 
 
completely agree (+1)
 
X

---

From: Pat Kinney <[email-masked]>
Date: Sat, 24 May 2014 12:29:23 -0500

Hi Qin;

It is my understanding that all of today's industrial TSCH networks always send ACKs during the same timeslot, however please note that they were implemented before 802.15.4e-2012.  

Although it is stated in 802.15.4e-2012 that: "Frames sent to a unicast node address require that a link-layer acknowledgment be sent in response during the same timeslot as shown in Figure 22b." it is also stated in 802.15.4e-2012:  "When operating in the TSCH mode (refer to 6.2.19.5), the enhanced acknowledgment frame is sent at the time specified by the macTimeslotTemplate being used (as described in 6.4.3.3.3 and 5.1.4.2a), i.e., macEnhAckWaitDuration should be set to a value corresponding to macTsAckWait."  

In the first quote, I note that "require" is passive, while in the second quote "should" indicates that it is only recommended.  Additionally, please note that there is no TSCH PICS item that states a requirement for ACKs being sent in the same time slot.  Hence, for the TSCH mode I find no mandatory requirement that enhanced ACKs be sent during the same slot as the incoming frame.  So, while it is certainly a good and typically expected practice to send an acknowledgement during the same time slot, units may choose not to do so and still be found to be compliant to the standard.

OK, enough for the legal stuff.  ACKs really should be sent quickly after the frame is received, this allows for more efficient use of network resources. To your example, what would take so long for the WrapperIE verification not to be processed within the time slot constraint?  It would be much better if the verification could be ready soon after the MAC payload is sent to 6top. Then the enhACK could be sent in the same time slot with the WrapperIE (CoAP-ACK). If the WrapperIE cannot be processed for within that time period for some reason, perhaps it would be appropriate to send the ACK/NACK time correction IE via the enhACK indicating NACK. 

Finally, to your point as to advantages/disadvantages.  In pre15.4e TSCH systems, the TSCH ACK is actually a data frame.  As per 802.15.4 (and ETSI 300 328), Data frames must use CSMA-CA before transmission causing additional time and energy spent as well as variable latencies.  Secondly, as per 802.15.4, transmission of Data frames cannot occur before a SIFS or a LIFS (depending upon frame size).  So an ACK frame is more efficient due to its lack of restrictions on transmission (e.g. no CSMA-CA nor SIFS/LIFS).

Pat

Pat Kinney
Kinney Consulting LLC

On May 23, 2014, at 8:56 PM, Qin Wang <[email-masked]> wrote:

Hi Pat,

Thanks
Qin

Pat

Pat Kinney
Kinney Consulting LLC

Hi Pascal,

What do you think?

Thanks
Qin

Dear all:

Would that make sense ?
 
Pascal

It implies that
 
Right?
 
Thanks
Qin 
 
completely agree (+1)
 
X

-Tom
===

Yes, that's what I mean.

 
 
Thomas

 

 
 
Tom,

 

Ideas?
 
Thomas

-Tom
=====

 
 
-raghuram

---

From: Qin Wang <[email-masked]>
Date: Sat, 24 May 2014 18:43:16 -0700 (PDT)

Hi Pat,

Many thanks for the detailed explanation. My further argument is as follows.

(1) It is not practice to require CoAP-ACK to be generated and then send back in a Enh-Ack in the same slot as incoming packet, because the 6top, which includes CoAP-for-6top, is asynchronized with MAC layer. Xavi has pointed out it in the previous email.

(2) If we agree on that Enh-Ack has to be send in a separated slot, then I think it has to follow the TSCH timeslot diagram, i.e. transmitting just after macTsTxOffset, otherwise, the receiver will miss the packet. Right? 

Thanks
Qin

On Sunday, May 25, 2014 1:29 AM, Pat Kinney <[email-masked]> wrote:

Hi Qin;

Although it is stated in 802.15.4e-2012 that: "Frames sent to a unicast node address require that a link-layer acknowledgment be sent in response during the same timeslot as shown in Figure 22b." it is also stated in 802.15.4e-2012:  "When operating in the TSCH mode (refer to 6.2.19.5), the enhanced acknowledgment frame is sent at the time specified by the macTimeslotTemplate being used (as described in 6.4.3.3.3 and 5.1.4.2a), i.e., macEnhAckWaitDuration should be set to avalue corresponding to macTsAckWait."  

Pat

Pat Kinney
Kinney Consulting LLC

Hi Pat,

Thanks
Qin

Pat

Pat Kinney
Kinney Consulting LLC

Hi Pascal,

What do you think?

Thanks
Qin

Dear all:

Would that make sense ?
 
Pascal

It implies that
 
Right?
 
Thanks
Qin 
 
completely agree (+1)
 
X

---

From: Pat Kinney <[email-masked]>
Date: Sun, 25 May 2014 12:29:21 -0500

While there are significant merits in not synchronizing 6top to the MAC, there are also significant merits in doing so (such as combining the MAC ack with the 6top ack).  Perhaps a compromise could be reached where some 6top behavior could be synchronized with some MAC behaviors such as when 6top receives a data frame containing a wrapper IE.

Agreed that when sending a TSCH frame, all timing requirements must be met, such as macTsTxOffset.  However, macTsTxOffset is configurable (1.8ms default) from 0 up to 65.5ms.  A time slot with a minimal macTsTxOffset and macTsTxAckDelay will maximize the amount of time allowed for an enhanced ACK.

In summary, if it is truly desired to totally decouple the ACK from the reception of a frame, then an 802.15.4 Data Frame must be used for that acknowledgment.  This would probably result in a MAC acknowledgment followed by a 6top acknowledgement, creating an increased energy usage and additional traffic.  But to allow a clever designer to decrease energy usage and increase throughput, I agree with the comment that 6tisch should not mandate that a 6top acknowledgement be sent with a separate frame from the MAC's enhanced ACK.  Perhaps this behavior could be a recommended practice

Pat

Pat Kinney
Kinney Consulting LLC

On May 24, 2014, at 8:43 PM, Qin Wang <[email-masked]> wrote:

Hi Pat,

Thanks
Qin

Hi Qin;

Pat

Pat Kinney
Kinney Consulting LLC

Hi Pat,

Thanks
Qin

Pat

Pat Kinney
Kinney Consulting LLC

Hi Pascal,

What do you think?

Thanks
Qin

Dear all:

Would that make sense ?
 
Pascal

It implies that
 
Right?
 
Thanks
Qin 
 
completely agree (+1)
 
X

-Tom
===

Yes, that's what I mean.

 
 
Thomas

 

 
 
Tom,

 

Ideas?
 
Thomas

-Tom
=====

 
 
-raghuram